Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!cs.utexas.edu!uunet!aplcen!haven!decuac!shlump.nac.dec.com!shodha.dec.com!FSCORE.dec.com
From: kaye@FSCORE.dec.com (Mark Kaye - He who dies with the most toys - is dead!)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Timestamps have to be UCT (was Re: 1.4 request)
Message-ID: <478@shodha.dec.com>
Date: 14 Nov 89 22:23:23 GMT
Sender: news@shodha.dec.com
Organization: Digital Equipment Corporation
Lines: 39

Timestamps
I just wrote some time routines for use on a large project that will be run
around the world. We have the problem that the operating system (VMS) doesn't
know anything but local_time, and some of the layered products only understand
local_time too. To get around this i designed a time structure as the following:
utc_time (in VMS time format - just use the time structure of current system)
local_time (VMS time format)
Timezone Code (1 character)
Daylight Indicator (1 character)

As you can see, both times are stored. When a program wants local_time, it
uses the correct field, while programs wanting absolute times (usually for 
sorting) use the utc_time. With the Timezone Code and Daylight Indicator it
is easy to write a few routines to convert from 1 timezone to another when
required.

The system can be either local_time or utc_time (you just have to know
which) and you calculate the unknown time once when the time is stored.
You also need a table to convert the timezone to some sort of numeric
offset to add/subtract to the time. It isn't easy! The world isn't
standardized on the values for Timezone codes, and some countries
still run on solar time (changes daily). I'm sure that CBM could
create a table (in preferences) that could assign a letter to each
timezone and we could live with that.

You also have to be careful when the Daylight Indicator changes. The
best way to handle this is to either speed up or slow down the system
clock for a short period of time to gain/lose an hour. This guarantees
that all times are still in correct order (the actual time won't be
accurate for the slow/fast period), but that usually isn't the comcern.

In the current software, we store the utc_time and the timezone and the 
daylight indicator and convert to local_time every time we want it. This
causes problems for those layered products that want a local_time in the
understood (VMS) format, which isn't possible. 

Mark Kaye		|		|				|
Box 172, Munster Hamlet	| 613-838-3580  | kaye@fscore.dec.com		|
Ontario, Canada K0A 3P0	|		| DEC fscore::kaye or kaye @kao	|