I am wondering if there are any good reasons to ever store time information in anything other that UTC (GMT)? I believe that this is a solid rule for all software engineering. The conversion to local time is merely a translation that happens at the UI layer for display purposes. I have also seen cases where the translatation is needed in order to implement an algorithm correctly (for handling midnight date changes, etc.).
+5
A:
I'd say it's application-dependent. I work on space physics models of the Ionosphere & Magnetosphere. We work with magnetic local time, storing date & times as Modified Julian Days.
Pete
2009-07-14 20:25:24
Your job sounds amazing to me :)
Scoregraphic
2009-07-15 09:53:20
Even then, there is a good case to be made for using UTC if there is any kind of round-the-clock activity. Otherwise, handling the daylight-savings crossovers becomes a massive PITA. I speak from bitter experience.
Ken Keenan
2009-07-14 20:30:20
Or if the time zone can be changed. A local times would have to be updated.
landon9720
2009-07-14 20:50:58
+3
A:
Alarms & scheduled tasks are sometimes stored in local time so that they aren't affected by Daylight Saving Time or timezone changes.
FigBug
2009-07-14 20:28:30
Pete
2009-07-14 20:34:38
@Pete: Think of my alarm clock: The alarm is set to 7am local time. When the clocks go back in winter, I do not want to be woken up at 6am. When I go on a business trip out west, I do not want to be woken up in the middle of the night just because it's 7am back home.
Dave Hinton
2009-07-14 21:00:30
@Dave Yeah, so you would just change TIME_ZONE += n, so convertToLocalTime(currentUtc, TIME_ZONE, isDaylightSavingsTime) would return the local time (even though it's stored internally as UTC).
Pete
2009-07-14 21:04:00
So for storing a time-of-day without any particular associated day, it can make sense to use local time. Good point.
Peter Cordes
2009-12-09 05:16:21
+1
A:
Ever? I'm sure there are good reasons in some isolated cases. In general, though, storing UTC is much better than local time, so I would treat UTC as the default position unless there's some special consideration.
Tim Sylvester
2009-07-14 20:39:31
+7
A:
In general it I find it better to use UTC. Sometimes you might need a local time. Then I would rather go with UTC + timezone information.
In general times can be extremely tricky for repetitive events, and you should very carefully analyze the use cases.
Imagine a recurring meeting, every Tuesday at 9:00 am. If the DST changes, the meeting should still happen at (the new) 9:00am.
But no add to the meeting some guys in France. For them the meeting is at 6:00pm. And they change the DST by a different rule.
When you change the DST, they don't, so for a while (until France changes DST) someone should be "off": either your meeting will be at 10am that theirs will stay at 6pm, or keep yours at 9am and move theirs at 5pm. There is no other way, computers have nothing to do with it.
How will an application decide who should be "fixed"? Is it the group with most members? (1 guy in US vs 20 in France?) Or is it about the importance of the person? (what if the 1 guy in US is the CEO?)
How do you store that info? My best solution is to use UTC + one "master time zone" The users in the "master time zone" win (stay fixed).
Things can get pretty tricky, but in general I have found the UTC solves more probelems than it introduces.
Mihai Nita
2009-07-15 09:40:19
+2
A:
In an embedded system you might well receive the time from a source in some sort of "ticks past epoch" form.
If the time is updated relatively frequently, and displayed relatively infrequently, then you might as well store it in the same way it's supplied to you and only convert it for display when needed.
In general, though, UTC is the way to go unless there are other considerations.
Vicky
2009-07-15 09:48:03
+2
A:
I'm in a situation now where I am building a system for storing personal user schedules etc.
At first I read everywhere that the data should be in UTC, as this is the best practice etc, and solves lots of problems.
But I'm not so sure. I want it to be that if a user changes their time zone, their appointments and deadlines will stay at the same local time, not shift around, otherwise all the repeating tasks would get completely messed up and only work for that one timezone.(without rewriting all the dates on timezone shift)
I'm a novice at this kind of stuff, so maybe I've just not thought about it enough at the moment.
Currently I'm going to use UTC +- timezone info for the scheduling of reminders etc, and then work with local time for user timestamps.
This situation maybe only arises because I am considering users moving through timezones, but I'll have to tell you how it works out in the end.
If anyone could warn me of some huge pit I'm digging for myself I would be eternally grateful.
optician
2009-11-10 00:22:14
For storing a time-of-day without any particular associated day, it can make sense to use local time. Any time you're storing something which can be represented as seconds-since-1970, you should probably store it as UTC, unless you've thought about exactly what you want to happen for all conversions. Or maybe if you're timezone-aware and you're going to store a timezone with the timestamp, i.e. you have an appointment in Halifax at 1pm local time (AST or ADT). Then that's tricky, because a human would expect local, regardless of whether the law changed to shift the daylight savings day...
Peter Cordes
2009-12-09 05:21:50
A:
UTC is a time-keeping standard that has the accuracy and precision of TAI, but with leap seconds added in at irregular intervals to allow it to closely track mean solar time (UT1).
If the system that you are working with cannot handle leap seconds, then the Bureau International des Poids et Mesures recommends that TAI be used instead of UTC.
Daniel Trebbien
2010-05-29 16:20:33