I have a feature request ...

Display in UTC

I travel a lot to different time zones and need to change the Windows system clock's time zone when I do. The ManicTime timeline displays in local time (I presume) so as a result I end up with 'overlapping' activities in my timeline. I suspect the labels then also overlap and are not added.
This would all be resolved if ManicTime would record and display in UTC.

28 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    info shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    13 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • AdminManicTime Support (Support, ManicTime) commented  ·   ·  Flag as inappropriate

        ManicTime stores data in UTC with timezone. So the problem is with the UI, not with storage.

        The problem this issue wants to solve is to have no overlapping time. And we could do this with UTC and for display use local time zone.
        But I hope everybody understands that this then changes all statistics.
        For example if I make a timesheet for my work now, then change the timezone and make the same timesheet, the data might not be the same, because all data is shifted with the new timezone.
        Similarly, lets say I work in timezone 0 and co-worker in timezone +10. If we use UTC, it makes a difference whether I make a timesheet of our work or he does. It will not be the same since my time is different than his time.
        So in my view, we would fix one problem (overlapping time), but we would create a bunch new ones.

      • David Matten commented  ·   ·  Flag as inappropriate

        What I mean is, it should not be an issue of "display" in UTC. That is not terribly useful, itself. If the timestamps are recorded and handled properly, display in local time should work fine. It is the serialization and DB storage that should be dealt with in UTC, let the local time display take care of itself.

      • David Matten commented  ·   ·  Flag as inappropriate

        Another place where this may come into play would be timelines sent to a Server from machines in different timezones. (Machines in use at the same time), as well as Calendar timelines from different people. They will be incoherent.

        This surprises me that it ended up this way. From working in my field, we learned long ago that recording things in local time will inevitably bite you. You can capture, manipulate, and display values in local time (probably preferable), but they should be converted to UTC for any storage or serialization.
        Beware of the serialization of the .NET DateTime object, though. Test the behavior with those "local" boolean fields, beware of defaulting valued when deserializing from both the wire, and from the DB.

      • Adam Law commented  ·   ·  Flag as inappropriate

        Yes with workers on different sides of the country it is very difficult. Espeically when they use a VPS, which if I log into, it goes back in time 3 hours and starts adding time

      • Zuriel commented  ·   ·  Flag as inappropriate

        I travel to different time zones and the way that the data is recorded or displayed is on the previous time zone and not with the time of the current time zone.

        Potential solution 1:
        Store the data in UTC and convert to the local timezone to display it properly.

        Potential solution 2:
        Allow selecting the time zone to use to display the timeline in the UI.

      • Joshua Carpoff commented  ·   ·  Flag as inappropriate

        I'd also say the ability to be timezone-neutral with tracking time should be a given. Crossing the International Date Line isn't handled as well. If all timestamps internally were stored UTC this would work fine.

      • AdminManicTime Support (Support, ManicTime) commented  ·   ·  Flag as inappropriate

        I think both are good options.
        If you travel for a day or two, then UTC makes sense. If you work in a timezone for a month, local time makes more sense. At least I'd rather see at which time I worked, not have everything change when I change the timezone. So it depends and it should be a setting.
        We were debating this when we started working on ManicTime, and decided to go with local time, thinking we would add the UTC later when we get some requests for it.
        Its not a simple change, we will take a look and make a time estimate. It would definitely help if the issue was requested by more users....

      • John commented  ·   ·  Flag as inappropriate

        This shouldn't even be a feature. To me it is a bug that Manictime doesn't handle changing timezones. Doesn't anyone at Manictime travel???

      Feedback and Knowledge Base