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 reference. - 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.
Comments?
------------------------------------------- Bill Dargel wdargel@shoshana.com Shoshana Technologies 100 West Joy Road, Ann Arbor, MI 48105 USA
squeak-dev@lists.squeakfoundation.org