Storing UTC? There *is* a good case for local time!
h.helwich at tarent.de
Tue Dec 21 10:18:32 CET 2010
Am Montag, 20. Dezember 2010 20:05:21 schrieb Georg C. F. Greve:
> Hi all,
> I am sure most of you know the following quote:
> "For every complex problem, there is a solution that is
> simple, neat, and wrong."
> -- H. L. Mencken
> I am afraid, this may apply to some extent to the idea to reduce complexity
> by storing everything in UTC. Allow me to try and explain the situation in
> a new way to help everyone get up to speed.
> Point #1: There is *ambiguity* in UTC
there is *no* ambiguity in UTC. UTC is the reference time for all time zones.
You can convert between UTC and local times without a problem.
> POSSIBLE SOLUTIONS:
> One way to address this would be to allow storing local time.
> This way a client could store the *intent* of the user and allow the
> clients to sort out the timing in the future when they can in fact be
> reasonably sure of the relationship between local time and UTC.
> The other way would be to store UTC, but also store the assumptions made.
> So in addition to the tz attribute, we'd have a DST attribute that would
> describe whether or not that client thought that DST would be in effect at
> this particular time - so clients can test that assumption and adjust the
> stored time where they now see the initial client was wrong.
> Both would allow to model all issues that I've seen so far.
> UTC storage alone, or even UTC storage + timezone are both
> oversimplifications of a fairly complex problem. So we'll need to introduce
> one more degree of complexity.
> The question is: Which one?
I think storing in local time would be the best solution.
If we look at this article:
It shows that it is in fact possible that the standard time somewhere might
So it is not enough to store the UTC time and a flag for DST to calculate the
intended local time. It is needed to store the offset to UTC that was active
at this time.
As i looked at RFC3339 i see that its not true that only UTC is possible. Also
local times like this are possible:
Perhaps this is a solution with which all are satisfied?
> Thoughts, opinions and proposals very much welcome.
> Best regards,
More information about the format