Is there ever a good reason to store time not in UTC?

Question

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. T

Answer 1

Alarms & scheduled tasks are sometimes stored in local time so that they aren't affected by Daylight Saving Time or timezone changes.

Answer 2

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.

Answer 3

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.

See: http://tycho.usno.navy.mil/leapsec.html

Answer 4

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.

Answer 5

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 problems than it introduces.

---

To clarify a (very valid :-) point from fjsj: by "master time zone" I mean the exact zone, including the info about DST active or not.

If you just store PT (Pacific Time), then it is not enough. PST (Pacific Standard Time) or PDT (Pacific Daylight Time) is.

Probably even better is not not think of recurring meetings as "a fixed point in time" expressed in seconds / milliseconds from the "epoch". Programming languages have (finally) started to adopt concepts from JodaTime.

Answer 6

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.