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.
Dave