TAI-based non-POSIX time_t
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