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

Hendrik Helwich h.helwich at
Tue Dec 21 13:36:05 CET 2010

Hi Georg,

Am Dienstag, 21. Dezember 2010 12:09:18 schrieb Georg C. F. Greve:
> 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.

Yes of course. The timezone information is needed when storing a local time. 
The UTC offset in the RFC3339 local time format is therefore not needed, but 
without this offset it would be no valid RFC3339 datetime value.

> 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?

Yes. Sounds good :-)

Best regards,

> Best regards,
> Georg

More information about the format mailing list