Storing UTC? There *is* a good case for local time!

Hendrik Helwich h.helwich at tarent.de
Tue Dec 21 10:18:32 CET 2010


Hi,

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:
http://www.worldtimezone.com/dst_news/dst_news_turkey02.html
It shows that it is in fact possible that the standard time somewhere might 
change.
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:

2002-10-02T10:00:00+05:00

Perhaps this is a solution with which all are satisfied?

Best regards,
Hendrik

> Thoughts, opinions and proposals very much welcome.
>
> Best regards,
> Georg




More information about the format mailing list