[Seaside] Re: Time Zone Point of Curiosity

[Alan Lovejoy]

Thomas Koschate <koschate <at> gmail.com> writes:

> 
> Whenever I load up an image from scratch, the Seaside installation
> process seems to have an almost pathological desire to adjust my
> image's time zone to Central European Time.  Why CET?  Why not GMT, or
> EST, or PST, or maybe even just assuming that I've already set the
> time zone that I want?

A tradition has developed in the software industry of setting the timezone to 
PST in situations where there is no reasonably good way to determine the actual 
local time.  Many PC-based operating systems do this.  The origin of the 
tradition is probably simply that many software developers reside on the west 
coast of the United States.  Apple and Microsoft would be prominent examples.

Modernly, applications rely on the host operating system to have its time zone 
correctly set to local time (and to handel DST transitions.)  

In a sense, Squeak does this as well, since its system clock runs in local 
time, based on whatever local time the host OS claims is correct. But Squeak 
has no idea what the current offset from Universal Time happens to be.  So, as 
long as the host computer and OS have local time correct, Squeak will also--but 
it won't know how local time relates to the equivalent time in any specific 
time zone, nor will it be able to authoritatively determine what the local time 
will be any number of seconds earlier or later than the current time (because 
it has no idea when the previous or next DST offset transition might be, if 
any.)

VisualWorks is another matter.  Its time zone functionality was added in the 
mid 1980s, back when PC operating systems worked totally in local time, and had 
little or no support for DST.  VisualWorks has always been more at home on Unix 
than anywhere else, and on Unix, the system clock runs in Universal Time.  So 
the VW primitive that returns the current time answers the count of time ticks 
(originally seconds, now microseconds) since 1901-01-01T00:00:00Z (which is the 
right way to do such things.)  But, if your current time function answers 
Universal Time, you'd better have a way of converting between Universal Time 
and local time, and that means you need to know the local time zone (including 
the rules for converting between local time and Universal Time.)

One way to handle conversion between local time and Universal Time is to 
implement time zones yourself (including the DST rules)--which is what 
VisualWorks did back in the 80's, when almost no one else had done so.  
Modernly, one can also rely on the OS to do it for you (which is the approach 
Cincom is currently attempting, although this change is being implemented 
gradually so as to avoid breaking existing code.)

You might wonder why VW (and others, such as the VW Seaside package) don't 
simply ask the OS what the local time zone is, and then set the VW TimeZone 
accordingly.  As it happens, I wrote a whole essay on that topic: Discovering 
the Local Time Zone--Why It's a Hard Problem [link: http://www.chronos-st.org/
Discovering%20the%20Local%20Time%20Zone--
Why%20It%27s%20a%20Hard%20Problem.html].