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

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.