Use for TimeZones (was: Time bug under Windows)

William O. Dargel wDargel at
Mon Dec 22 08:18:53 UTC 1997

Tim Rowledge wrote:

> Take care for what you ask, Bill. If you have it available, take a
> look at the code required in VisualWorks to handle this stuff.

I don't have VisualWorks to look at, so I don't know what you might be
referring to here.

> Then think if you really want it...
> It turns out to be surprisingly tricky to deal with timezones and,
> IMHO, surprisingly rarely useful.  Everyone should stick to GMT
> anyhow!

But not everyone wears a watch that is set to GMT :-)

Actually I would agree that for any application where it might matter, a
universal time should be used internally. That would include apps that
operate across multiple time zones, and those where durations are
important even when they span changes to daylight savings time.

Since "Time now" answers the local time, we immediately would have a
need to handle time zones one way or another if we wanted to convert it
to UTC. And since most users want to deal with things in local time, we
have a general need to convert back and forth between local and
universal time. I guess I don't follow why you think this would be
"rarely useful".

One suggestion might be to add 4 new classes (in addition to the current
Time and Date).
    - TimeEvent - a Magnitude that specifies both a date and a time,
though encoding of the implementation is open for debate. (Seconds from
a base is one possibility). One-second accuracy would suit me. Provides
for general support without being tied to any specific frame of
    - UniversalTime - a TimeEvent with a universal reference. GMT for
all intents and purposes. (Does anyone know offhand what the differences
are between GMT and UTC?)
    - LocalTime - a UniversalTime plus the TimeZone it references.
    - TimeZone - name(s) plus a representation of the rules (including
daylight savings time) needed to map between universal and local times.


Bill Dargel            wdargel at
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

More information about the Squeak-dev mailing list