How to conclude KEP2 for good
Georg C. F. Greve
greve at kolabsys.com
Tue Apr 5 14:33:00 CEST 2011
On Tuesday 05 April 2011 10.45:04 Jeroen van Meeuwen (Kolab Systems) wrote:
> Too bad that the assumption Georg made is faulty to begin with. When
> storing UTC, there is no "DST Assumption" just like there is no UTCWND or
> UTCWSD - this terminology has been made up to confuse and justify the
> argument and bears no weight at all.
My apologies. As discussed, I did not realize you were no longer proposing
what you wrote in your mail
where you write:
- During the summer, user decides he wants a weekly 11am company meeting
and is in Zurich.
- Writes out 10 UTC, Europe/Zurich, as the baseline offset is +1 -and does
not write out 9 UTC accounting for the current DST offset to UTC.
- During the winter, user decides he wants a weekly 11am company meeting
and is in Zurich,
- Writes out 10 UTC, Europe/Zurich, as the baseline offset is +1
According to that, 11:00 in Europe/Zurich gets written out as 10:00 UTC with
or without DST in effect, or, to put it in your words from the same email:
"While the specification could just say that datetimes should always be
written out as if no DST was ever invented, I'm sure that leaves too much room
Trouble is, DST exists, and 11:00 in Europe/Zurich *is* 09:00 UTC right now.
This is a legally binding hard technical fact: A value of 10:00 is *not* UTC.
This is not a neglegible minor political offset issue, it is just wrong.
So what the proposal implicitly did was to invent a new timezone for which DST
handling is effectively rolled into one with UTC, greatly simplifying the
writing, but at the cost of requiring to untangle them again before being able
to use the data. Hence the attempt to communicate this by naming this time
zone "UTC With No DST" (UTCWND) as in "as if no DST was ever invented" from
the original proposal.
My apologies if that was not semantically agreeable to some, and may have
caused confusion for others.
But as I wrote before: This proposal seems to have been off the table without
my noticing, so I may have been flogging a dead horse. Apologies for that.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/kolab-format/attachments/20110405/c2cea272/attachment.bin
More information about the Kolab-format