Lex --

I like your suggestion ...

Cheers,

Alan

------

At 9:59 AM -0800 11/24/99, Lex Spoon wrote:

Tim Rowledge rowledge@interval.com wrote:

...

On Tue 23 Nov, Lex Spoon wrote:

...

I keep hoping someone will jump up who understands time zones and calendrial calculations and such and implement something in Squeak that can be easily ported around.

Oh my, that's a _lot_ to hope for! At PPS some years ago we had a multi-day mailstorm about timezone stuff that generated enough hot air to send Branson across the Atlantic. Conclusion: it's _damn_ complicated. Basically you need a way to read the time and your machine's timezone, plus a way to convert from one TZ to another.

The good news is that by now all the OS's we use have at least some understanding of timezones, where back then many didn't. I don't suppose there is a website that offers zone/time conversion ? It may well be simplest to pass the job off to a server somewhere. Some timezones have a partial hour offset. Some have wierd rules for daylight savings time start/stop. Some appear to have no 'rules' - IIRC, UK DST is set on a year by year basis. Some have many names. Ugh.

Hmm, okay, it would be kind of a shame to have 10k lines of code floating around the smalltalk image just to deal with this one issue. Though it's always nice to have things that are quietly Done Right, it's also nice to have code proportional to the benefit you get from it.

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

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