Can only aggree with the previous comments.

Recording should of course be in UTC, everything else is doomed :-)

Displaying should be selectable including "automatic" which is the device timezone.

I turned on the computer and started working on things. I didn't notice the time wasn't updated. An hour or so later the time automatically synced to the right time due to daylight savings and I didn't think anything of it until now when I looked at ManicTime and can see that there is time overlapping during that period.

I can delete the computer usage time but the applications and documents are still overlapping. I'm sure autotags would be overlapping too if I had more of those today.

I guess I can just tag them twice but why is this still an issue after 4 years? It seems like it wouldn't be that hard at all to just store all things in UTC and display them in whatever local time I use in the client. I'm not even using the server, just the Windows desktop client anyway.

The title of this thread is Display in UTC. I really think the applications should allow us to display in whatever timezone we want and permit that we change timezones freely. It would be shortsighted to deploy this feature as "local timezone or UTC". This features should really titled "Display in ANY timezone"

Don't let this reply negate or hide the fact there is a bug with how Android timelines are saved on a server when the android and server are in different timezones. There is clearly a bug somewhere.

This needs to be fixed. As commented below by John on March 2016 - yes over three years ago, "To me it's a bug...". Even if this type of functionality was intentional, I agree it's simply a BUG.

Why? I live in Germany UTC+1 however my employment is actually in the Eastern USA UTC-5. I use ManicTime on my Android phone to track phone calls and locations. The phone is in German time. My office computer is set to the Eastern USA. So when I look at my timelines all my phone activity is offset, but not like you would expect. NOTE: I have a client/server deployment with ManicTime Server in Eastern USA.

For examplem my 08:00 phone activity in Germany shows up on my USA based ManicTime server as 14:00. Which is actually completely backwards. 08:00 in Germany is actually 02:00 in the Eastern USA. This is very confusing and difficult to account for. Also Germany isn't always six hours off from Eastern USA. Sometimes its only five hours (Germany and USA don't change to/from Daylight Saving Time on the same schedule). If ManicTime really does store everything in UTC and only presents it to us via the client then why is there a difference between these timelines. My phone times are clearly being stored with the wrong UTC offset. My phone data is being misrepresented in the Windows desktop client as happening 12 hours later than it really did. This is clearly a bug and requires immediately attention. I don't know if it's the ManicTime Server or Android client that is causing this issue.

I'm sure I'm not the only person traveling with their phone, or what about people who live near a timezone border and their phone automatically adjusts by 1 hour. Those people's phone time lines must be all messed up. Clearly the server is taking the phone data and improperly modifying it and NOT storing in proper UTC.

As for changing timezones and the affect on statistics. In my case the statistic reports are mostly generated by servers. So changing the server timezone would be the only situation we'd have a problem. We don't move our server so I don't see a huge need.

As for users of just the desktop product then if the user changes their timezone, how about displaying a warning? Ultimately I certainly understand how statistical reports based on "e.g. who arrived to work the earliest" could be confusing with multi-time-zone groups but this goes back to the Server setups. For desktop users if they move locations then the statistics are probably less important. Regarless, as more and more of us work from various worldwide locations, this simply needs to be addressed logically and failing to adhere to UTC is no longer possible for a product such as ManicTime.

I would argue this is the biggest issues for ManicTime right now. The product works great otherwise and huge benefit for us. Thank you for a great product. Now let's take it to the next level and make it work for worldwide organizations.

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.

the request http://support.manictime.com/forums/222041-feature-requests/suggestions/12890121-display-in-utc

should be merged into this one. This is a better description of the problem, and "solution 1" here is probably the best approach

This should be merged into http://support.manictime.com/forums/222041-feature-requests/suggestions/31028293-show-the-correct-timeline-when-travelling-to-diffe

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.

Even 1 hour differences can turn calculating time very complicated. +3

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.

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???