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

Georg C. F. Greve greve at kolabsys.com
Tue Dec 21 12:09:18 CET 2010


Hi Hendrik,

On Tuesday 21 December 2010 10.18:32 Hendrik Helwich wrote:
> > 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.

There is no ambiguity as long as you stay inside of UTC, true.

But once you need to translate to local time you run into an ambiguous 
relationship between UTC and local time, because the UTC offset is changing 
throughout the year and - as you demonstrated with your example of Turkey - 
can even change completely.


> I think storing in local time would be the best solution.

I think you might be right.

There is definitely a strong case made for this by the ambiguities in the many 
UTC to local time relationships.


> 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

Indeed.

This is still not totally unambiguous, as an offset to UTC does not specify a 
time zone, e.g. UTC-0300 can be any one of the following:

# ARGENTINA (Buenos Aires)
# BRAZIL (Rio de Janeiro dst, Sao Paulo dst, Brasilia dst)
# BRAZIL (Recife, Maceio, Salvador, Fortaleza)
# FRENCH GUIANA (Cayenne)
# GREENLAND (Nuuk=Godthab dst)
# SAINT PIERRE AND MIQUELON (Saint-Pierre dst)
# SURINAME (Paramaribo)
# URUGUAY (Montevideodst)

And as these are different countries on different hemispheres with different 
dates and directions (!) of switching DST, the offset to UTC does not identify 
the actual DST regime. So in other words, the tz attribute and Olson database 
will still be necessary.

But the combination of local time in RFC3339 notation, and Olson time zone 
information should allow to correctly map all cases, I think.

 
> Perhaps this is a solution with which all are satisfied?

I think so.

To summarize, we're now both thinking that we should do the following:

 * store local time in RFC3339 notation
 * tz attribute as geographic reference to Olson database

and if an event should be sticky to UTC, it gets stored in Zulu notation as 
before with an explicit tz="UTC".

Would you agree?

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101221/c414ca31/attachment.sig>


More information about the format mailing list