On Wed, Nov 24, 1999 at 09:59:15AM +0000, Lex Spoon wrote:
> 
> Maybe to get started, we should simply add a "localtime" primitive to
> Squeak, which returns a tuple of both the global (GMT) time, and an
> offset from it to get to local time?  This would avoid a lot of
> conversion messes, and constrained platforms could simply implement the
> local-time offset as a constant somewhere.  There is already a basic
> dateAndTimeFromSeconds: implementation in class Time, so maybe this
> primitive would take us a long way.
> 
> What do ya'll think?
> 
> Lex
>

Good idea. I'm willing to help with a pluggable primitive for Unix,
which should at least prove the idea out.

But before anyone writes any code, let's look at the excellent
guidelines recently posted by Eric Ulevik. They lead me to think
that we need a way to express the idea of an underlying time continuum
with points on the time line represented as magnitudes, conveniently
expressed as seconds (or milliseconds) since the dawn of time.
(We'll end up using LongInteger representations, so we may as well go
ahead and use milliseconds since the dawn of time, just in case we
ever get around to something approaching real time Squeak. But that's
another discussion entirely.)

A good prerequisite for this is to agree on what constitutes the
origin of time. Squeak defines this to be the January 1, 1901, but is
not clear as to whether this refers to the January 1, 1901 at the
Xerox PARC labs, or to January 1, 1901 at the international date line.
I would suggest that we adopt the latter, unless someone is motivated
to research the time zone conventions in use at the turn of the 20th
century in California. We'll keep Dr. Einstein out of the discussion
as a matter of expedience.

I would suggest an associated Smalltalk class called something like
"PointInTime" to capture the notion of a point on a universal time
continuum, as opposed to a "Time" as displayed on a wall clock.
The current value of PointInTime is the number of seconds (or milliseconds)
since the first instant of the day of January 1, 1901, as experienced
by a person sitting in a boat located on the equator at the international
date line.

Most operating systems can readily convert to and from their own concept
of the dawn of time, so we would now have a conceptual representation
of location-independent time, primitives to report its current value, and
a Smalltalk class to represent points on the time continuum.

The things that must be created are:

1) A primitive to answer seconds (or milliseconds) since the dawn of time.
We should not use the existing Time>>primDateAndTimeNow because it is not
a monotonically increasing function (its values jump forward and backward
when you cross a daylight savings time boundary).

2) A primitive to answer the offset of local time versus UTC, for purposes
of calculating local time and date. This offset varies by timezone as
well as by the effect of daylight savings time conventions.

3) A primitive to answer the name of the local time zone, for use in
displaying time and date as printed strings.

4) Some Smalltalk code to make Date and Time do the right thing with
the new primitives, or fall back on their previous behavior when the
primitives are not available.

Neither the offset nor the name of the timezone changes very often for
any given physical location on the globe, so it is not really necessary
to code a primitive to answer both UTC and local time "simultaneously".
I'm not really sure at this point whether it would be best to do this
as three separate primitive calls, or one call answering an array of
three objects, or some combination. It's easy enough to try it a few
different ways, I suppose.

- Dave