On Thu, Dec 19, 2002 at 11:59:43PM +0100, tblanchard@mac.com wrote:

Are we expecting to add TimeStamp to the base image in 3.4? It seems awfully useful. If so, are there plans to introduce timezone support?

FWIW, see TimeZone at http://minnow.cc.gatech.edu/squeak/1076. I haven't touched it in a couple of years, but it still works fine in Squeak 3.4.

This was my attempt to contribute to the grand millenium hoop-de-doo. I think it hold up better than some of the other work that was undertaken in support of the Y2K scam.

Dave

p.s. In anticipation of your next question: Yes, of course leap seconds are supported. How could you possibly hope to do a proper timestamp without accounting for leap seconds? ;)

On Fri, Dec 20, 2002 at 08:59:27PM +0100, tblanchard@mac.com wrote:

Actually, I'm trying to add support for a web app and want ISO-8601 read/write support. 1997-12-17 07:37:16-08 - so the timezone is just specified as an offset [+-]hh:mm

I'm having trouble figuring out how to do this with the package (which looks good BTW).

Your local time zone is represented by "TimeZoneDatabase systemDatabase defaultTimeZone" or "LocalTimeTransform here"

The names of all time zones in your database are "TimeZoneDatabase systemDatabase timeZoneNames"

On my system, there are three timezone definitions available for Amsterdam: "TimeZoneDatabase systemDatabase timeZoneNames select: [:tz | '*Amst*' match: tz]"

For your purposes, the time zone for Amsterdam is represented by "TimeZoneDatabase systemDatabase timeZoneFor: 'Europe/Amsterdam'"

The current offset in seconds from UTC in Amsterdam is "TimeZoneDatabase systemDatabase offsetFor: 'Europe/Amsterdam' at: PointInTime now"

The current offset in seconds from UTC for your local time zone is "TimeZoneDatabase systemDatabase offsetFor: TimeZoneDatabase defaultLocation at: PointInTime now"

There is a database entry for the 'UTC' time zone, and its current offset is zero "TimeZoneDatabase systemDatabase offsetFor: 'UTC' at: PointInTime now"

I did not write any methods to do ISO 8601 formatting. If you do this, I would suggest putting them in the "converting" method category of class PointInTime, perhaps something like PointInTime>>asISO8601String.

See the class comment for PointInTime to see how "time" is being represented (it's fundamentally different from the base Time and Date classes). The class comments for LocalTimeTransform, TimeZoneRuleSet, and TimeZoneDatabase will hopefully provide a good explanation of how the rest of this mess works.

Note that I did this stuff before the TimeStamp classes existed (I think). I have not checked to see if there are any conflicts.

Patches for ISO 8601 formatting and/or merging with TimeStamp classes are welcome. Feel free to update the swiki page directly.

HTH, Dave

tblanchard@mac.com wrote:

I've been working on type conversions for the PostgreSQL driver and was amazed to find that TimeStamp is not in the base image and appears to be bundled with SqueakMap?!?!

Yep! :-) Its originally from Comanche and I would of course like to see something similar in some form of base image/package but I didn't want to wait for that to come about before publishing SM.

But I agree, let's cut it out from both Comanche and SqueakMap and put it in some neat little DateAndTime package which can contain these things. :-)

The TimeStamp class that is provided is a simple pair of Date and Time

• which is alright in isolation but I think we would need a TimeZone to

provide for universal timing across images. But I don't see any TZ support. How is this handled now wrt to things like DVS where the server may be in a different timezone than the client? Or is it?

Are we expecting to add TimeStamp to the base image in 3.4? It seems awfully useful. If so, are there plans to introduce timezone support?

-Todd Blanchard

No plans but as David Lewis pointed out, there has been work in this area. I am not familiar with it but remember that I thought it looked very "thorough".

It should of course be in a package though.

regards, Göran

Lex Spoon lex@cc.gatech.edu said:

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.

Consider, say, webmail. Our webmail login (http://www.theinternetone.net/cgi-bin/sqwebmail) asks for your local timezone, so mails you write have the correct Date: header. For this, it must be able to make all the necessary calculations to convert its local OS timezone into whatever the user indicates (including winter/summertime).

So the image should be able to make time calculations with arbitrary timezones, IMHO.

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