TAI-based non-POSIX time_t

Andrew Brown atatat at atatdot.net
Thu Apr 15 05:01:49 UTC 2004


On Wed, Apr 14, 2004 at 09:17:24AM -0400, John Cowan wrote:
>Markus Kuhn scripsit:
>
>> Reason 2: Local-time errors affect critical long-term state such as
>> file-system timestamps much less, as these tend to be in UTC. (Just
>> an hour ago, we discovered a machine that had its default time zone
>> set to US East Coast local time instead of London local time. We were
>> able to fix that problem on-the-fly without any disruption, as most
>> system state remained unaffected. The machine knew UTC accurately
>> to within 2 ms all the time.)
>
>Then again, there was my colleague's Windows system, which was still
>running on Redmond time instead of New York time.  Unfortunately,
>we couldn't fix it, because the thousands of appointments, past and
>future, that he had stored in Outlook's calendar would then all be
>off by three hours.
>
>Consequently, his email tended to arrive from the future.

you can't fix that.  unless you can convince microsoft of the value of
utc time and a utc time_t sort of time stamp.

i know they use something loopy like "64 bit count of milliseconds
since jan 1, 1600" somewhere (or something like that), but a plain old
time_t is a very handy thing.  even if it only has a little less than
34 years left to live.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior at daemon.org             * "ah!  i see you have the internet
twofsonet at graffiti.com (Andrew Brown)                that goes *ping*!"
werdna at squooshy.com       * "information is power -- share the wealth."



More information about the tz mailing list