tblanchard at 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?!?!
> 
> 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?
> 

Don't overlook the ANSI DateAndTime class, included in the ANSI patches,
which appear to be the same thing.  I would love to see *all* of the
ANSI patches appear in a new version.  They do not cause trouble, and
they are better thought out in some cases than what is in standard
Squeak.  They also do not commit us to being ANSI compatible at all
costs.

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.


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.  

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.

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


-Lex