[geeks] DST hell

[Jonathan C. Patschke]

On Sat, 10 Mar 2007, Mike Hebel wrote:

>> As a "for instance" - say I've got a database that is storing
>> date/time stamps in UTC, but my users want to see DD/MM/YYYY HH:MM,
>> after the code retrieves the timestamp, the application will need to
>> convert it (or your DB will have to convert it, same diff really)...
>
> If you're talking posted transaction dates/times and such then as long
> as the desktops point to something that is DST patched for their time
> sync then why would it matter?

Because DST doesn't change what time it is, only how the time is
displayed to the user.  The amount of time since the epoch does not jump
an hour at the DST boundary, and every sane clock-synchronization
protocol uses a delta-since-epoch time base, not local time.  Otherwise,
you'd have to know the time zone of every NTP server you connect to.`

That is, of course, unless by "DST patched for their time sync" you mean
to tell the time server to lie about the time by a factor of one hour
for three weeks in March and one week in October in order to work around
patching desktops.  For, if you were to do that, far, FAR more things
would break[0] at each of your four boundary points.


[0] because it breaks the assumption that time-since-epoch monotonically
     increases at a specified rate.  DST does not do this.
-- 
Jonathan Patschke ) "I would buy a Mac today if I was not working at
Elgin, TX        (   Microsoft."      --Jim Allchin, VP of Platforms