TimeStamp is part of SM?

David T. Lewis lewis at mail.msen.com
Mon Jan 6 04:51:02 UTC 2003

On Sun, Jan 05, 2003 at 02:39:23PM +0300, Lex Spoon wrote:
> The only bad part of the DateAndTime is that the support for getting a
> timestamp-plus-offset from the OS never got put into the main
> distribution of the ANSI patches.  This is extremely simple, but you do
> have to add a primitive to the VM.  The primitive is even quite
> portable: gettimeofday() provides all that you need, and this function
> is probably widely available.  The primitive simply returns both the
> local time and the UTC time, which can be conveniently encoded as two or
> four integers (I forget how many).  I even coded this up once, but it
> never gained much interest for some reason.

I saved the code if anyone wants it.

> Also, the ANSI patches do not include much support for real timezone
> calculations.  For example, they don't let you convert a UTC time to an
> eastern US time.  However, note that this kind of calculation is quite
> tough.  

A dumb time zone representation which just knows about its current
UTC offset is probably adequate for most purposes. As you say, doing it
right is rather complicated.
> At the least, a package supporting this stuff should probably restrict
> itself to the timezone that the machine is running in; every country in
> the world is allowed to have its own timezone regulations, and so
> dealing with arbitrary timezones sounds quite tough.  As a practical
> Unix example, consider curses and its termcap database.  It's hard to
> keep the databases up to date on every machine you use, and ultimately
> you even run into people using a string like "xterm" to mean different
> things!  Timezone databases would likely have similar problems, even
> though they are more carefully regulated.

Agreed. A time zone database is necessarily rather large, and should
be loaded only in images that need it, such as an image running a web
application. Of course, a community minded person might want to make
it available as a service on the net that any Smalltalk image could
query.  Come to think of it, that would make a nice student project
at a university which uses Squeak.

> I'd be happy to be shown otherwise--ie, that there is a timezone package
> floating around which has tons of support, as opposed to just reading in
> the raw database from disk.  If someone has worked out some thorough
> timezone calculation for Smalltalk, that would certainly be excellent. 
> (Though I'd still wonder how often it is useful, as compared to the
> simple UTC-plus-offset).

Keeping the database up to date is awkward if everyone has their own
copy of the database. Again, a network based service would be nice.
The calculation part is not bad, and I think I've got it worked out
pretty well in TimeZoneDatabase (available on SqueakMap).

Note by the way that the UTC-plus-offset that you get from your
operating system (unix/linux I presume) is identical to the results
you will get from TimeZoneDatabase if you load the database with
the time zone files on your system. They're using the same time
zone data files, it's just that TimeZoneDatabase does it all in
Squeak so you can watch the bits moving around.  And of course
it becomes bit-compatible on any OS once it's loaded into the
Squeak image.


More information about the Squeak-dev mailing list