> > PS. We also use the Timezone stuff from David Lewis and that also ties
> > into this using class PointInTime etc. Phew. 
> 
> David developed his class in isolation - I only learnt of it when he announced it.

FWIW, I posted the timezone stuff back in 1999. Just for laughs, here
is from my original post:

  Date: Wed, 22 Dec 1999 11:18:47 -0500
  From: "David T. Lewis" <lewis at mail.msen.com>
  To: squeak at cs.uiuc.edu
  Subject: [ENH][GOODIE] Time Zone Support for Squeak
  
  As the end of the millenium nears, I am moved to attempt the creation of a
  work of enduring value and social import: A Squeak utility for scheduling
  New Years Eve celebrations in synchronization with the coming of the year
  2000 in every known time zone around the world. Particularly ambitious
  revelers may elect to hoist a cup twice for each geographic zone, once for
  each time zone as represented casually on most computers, and once again 22
  seconds later in recognition of the influence of leap seconds on local time
  observances.
  
  Of possible incidental interest to more sober observers of the millenial
  transition, I am including a time zone database which can be initialized
  from data in tzfile formatted time zone files as found on many newer Unix
  systems, especially Linux and FreeBSD. The database answers UTC offsets for
  each time zone at any point in time, and includes leap second compensation
  for time zones whose tzfile data includes a leap second table.
  
  After loading the change set and initializing from the time zone files on
  your computer (or from a small set of representative files which I have
  provided as examples), inspect "TimeZoneDatabase partyTimes" to obtain the
  essential revelry schedule.
  
  Happy New Year!

> Much of the features he offers are related to time zones. The existing chronology
> package does support the basics of time zones with an eye to adding daylight saving
> later. 

Exactly so. My time zone stuff does not do any of the calendar related
things in Chronology, and there should be no conflict at all between the
two. After Chronology was incorporated into Squeak, I added some hooks
to assist in time conversion with time zones. I used your time zone
hooks, and it works just fine.

The PointInTime class in TimeZoneDatabase is there for two reasons:

1) I wrote it to support Squeak, ST/X, and VisualWorks, and needed
something that worked across Smalltalk platforms.

2) I needed an abstaction for absolute time independent of the
earth-rotation representation of time (calendars, etc). Without
that, it's pretty hard to get things like leap seconds right.

> I did not add that as I live in a country with only one time zone
> and no daylight saving. There is no reason Dave's functionality
> could not be included.

Agreed, although I would have to say that most people do not need
a good time zone representation for everyday use. It's a rather
large package so it really should to be kept separate from the base
image. It's easily loadable by anybody who does need it, so I think
it's best to keep it as an external package. Probably most Seaside
applications would want to have it available, but the majority
of Squeak users probably would not.

Having said that, I think there is something to be learned from
the PointInTime class. On recent Squeak, it uses ScaledDecimal to
represent time values. This turns out to work really well. You can
represent any precision you want (not just milliseconds, nanoseconds,
or any other specific granularity). And as a practical matter, the
actual time values the are reported by the underlying system are
always integral values, which causes time arithmetic based on
ScaledDecimal to be very efficient.

Dave