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.
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.
should be merged into this one. This is a better description of the problem, and "solution 1" here is probably the best approach
which actually fewer, but a comparable number of votes (possibly double-votes), but is a better approach to handling the underlying problem with the timelines.
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.
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.
Jane Check commented
Even 1 hour differences can turn calculating time very complicated. +3
Adam Law commented
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
Think about teaming up with the Drive Software guys who make Atomic Alarm Clock. http://drive-software.com/atomicalarmclock.html You could tick a few feature requests here.
Yes this is very important
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
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.
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....
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???