[Kolab-devel] KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

[Andrew McMillan]

On Tue, 2010-11-23 at 16:17 +0100, Jeroen van Meeuwen (Kolab Systems)
wrote:
> 
> I'm saying that the "+0200" is a problem, because the number is
> subject to local UTC offset changes, such as is the case with DST.
>  There is virtually no way "+0200" can be reliably resolved to the
> indended UTC datetime, as we have no indication of the authoritative
> location for which the +0200 was originally intended; and thus also no
> rules we can use on UTC offset changes.

No, in fact +02:00 *only* describes an offset from UTC.  It *cannot*
describe a timezone, because it does not tell us anything about the
legislative domain responsible for changes to that offset in the past or
the future.

So in many ways it is equivalent to a UTC time as there is an invariant
calculation (subtract two hours) which converts it to UTC.  It does also
tell us a local time.

It seems a common error to believe that an offset from UTC is a
timezone.  It is not.  When provided along with a time it does describe
a *local* time, certainly, but since it is a local time in several
different localities we cannot reverse the transformation to decide
*which* of those localities is the legislative domain responsible for
defining past or future changes to that offset.

Of course there might be rare cases where an offset from UTC *does* map
to a *single* timezone, and so in such cases we can reverse the
transformation, but these are very much the exception rather than the
rule.

Just for fun, there is an interesting bug once filed against Mozilla
Calendar (#328996) for guessing people's timezones on the basis of their
UTC offset which went spectacularly wrong for a significant global
population (I recall having some fun calculating the numbers affected by
this) since it used the first timezone matching the user's offset as the
user's timezone.  New Zealanders were all relocated south to Antarctica,
but the timezones for Japan, France and UK, Australia and others were
also hilariously mis-guessed.


> Hence, the proposal would introduce an Olson database location entry,
> from which we can always calculate the intended offset; for millennia
> to come, hopefully.

Or for as long as DST lasts...  which many of us who have been late for
meetings, or found ourselves arriving at work when there was nobody in
the office, would wish to be a short time indeed :-)

Cheers,
					Andrew McMillan.

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
                If you can read this, you're too close.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.kolab.org/pipermail/devel/attachments/20101124/b0c0446b/attachment.sig>