Time Zone Point of Curiosity

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?
--
============================================================
Thomas Koschate
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thomas Koschate a écrit :
> 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?
Hi Thomas,

Since the VW installation of Seaside does exactly that,
I am assuming that you are a VW user. If you are a Squeak
user, you do not need to read further.

As to why CET, the time zone in the VW base image is PST.
So why PST ? Probably because most of the VW engineers
reside in California and this probably makes their work easier.
So why CET for Seaside? Simply because I reside in France
and this makes my port work easier.

In the first dialog that pops up during Seaside installation,
there is a check box that say "Set time zone to CET".
You may want to uncheck it before pressing the OK button,
then the time zone will be left unchanged during installation.

If you are using the SeasideSettings parcel, there is also
an option in the Seaside installation settings that allows
you to disable the change of the time zone. This can also
be set programmatically prior to installing Seaside.
    WASettings default changeTimezone: false

HTH
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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









_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alan Lovejoy wrote:
> 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?


> 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

Well, we have a locale plugin for a while now, which allows you to query
for the local time zone. At least that's what the API suggests, not sure
it is implemented on all platforms yet.

Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michael Rueger <m.rueger <at> acm.org> writes:
Squeak
> > has no idea what the current offset from Universal Time happens to be.  So,
as
>
> Well, we have a locale plugin for a while now, which allows you to query
> for the local time zone. At least that's what the API suggests, not sure
> it is implemented on all platforms yet.
>
> Michael
>

Well, that's better than nothing--although "experimental" code (that's not well
known, isn't installed by default, and may not work on all platforms) just
doesn't make the grade.

Also, the API is underpowered.  It only promises to provide a boolean flag that
indicates whether or not DST is currently in effect, and to provide the current
local time offset from UT (in minutes.) Although that's better than nothing,
what's needed for minimally-acceptable functionality is a function that
provides the local timezone's offset from UT for any point in time (where the
point-in-time is an input of the function.)  Anything less than that makes it
impossible to correctly do date/time arithmetic, or to correctly translate
timestamps to or from other timezones.  One reason this is so is because not
all timezones change their offset by a full hour for DST. Another reason is
because adding or subtracting even a fraction of a second to or from a point
int local time might cross a DST transition.



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alan Lovejoy wrote:

> Well, that's better than nothing--although "experimental" code (that's not well
> known, isn't installed by default, and may not work on all platforms) just
> doesn't make the grade.

Feel free to add the required functionality, it's OpenSource, you know...

Michael

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Sat, Dec 16, 2006 at 01:52:36AM +0000, Alan Lovejoy wrote:
For Squeak, the TimeZoneDatabase (on SqueakMap) handles this. It uses
actual Olson time zone tables, so no plugin is required, and it's integrated
with Squeak's Chronology classes so that durations are correctly calculated
across DST transitions and so forth. The tables can be updated to keep up
with new time zone rules. Typically you would just load them from the
zoneinfo files on your server if it's a unix box.

Most Squeak users have no real need for this, but it might be quite useful
if you are implementing a Seaside server with users in different time zones.

TimeZoneDatabase has been around since 1999, so it's fairly stable. I
don't know how many people actually use it gets though; probably not
too many since I rarely hear mention of it.

Dave

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 12/16/06, David T. Lewis <[hidden email]> wrote:

> TimeZoneDatabase has been around since 1999, so it's fairly stable. I
> don't know how many people actually use it gets though; probably not
> too many since I rarely hear mention of it.

We use it in Dabble DB, and it's worked well for us.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Sat, Dec 16, 2006 at 11:13:09AM -0800, Avi Bryant wrote:
> On 12/16/06, David T. Lewis <[hidden email]> wrote:
>
> >TimeZoneDatabase has been around since 1999, so it's fairly stable. I
> >don't know how many people actually use it gets though; probably not
> >too many since I rarely hear mention of it.
>
> We use it in Dabble DB, and it's worked well for us.
 
Thanks Avi,

That's nice to hear.

Dave

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

David T. Lewis <lewis <at> mail.msen.com> writes:


> For Squeak, the TimeZoneDatabase (on SqueakMap) handles this.

Your TimeZoneDatabase handles time zone offsets and transitions, and is a good
solution, especially for applications running on BSD-Unix-based hosts, where
one can expect to find a repository of binary tz files at pathnames that are
easily derivable from the Olson time zone name, and where the /etc/localtime
tzfile can be found that contains the offset transitions for the system's local
time zone.

But for HP-UX, for some flavors of AIX, for some other non-BSD Unixes, and of
course for any non-Unix machine, the situation is not so favorable.  Certainly,
one can install a tzfile repository on any machine, and on Unix machines one
may be able to put the localtime binary tzfile (or a symbolic link to one) in
the /etc folder (if the system admin is friendly.)  But managing the logistics
of all that (including the small detail of letting one's code know where the
files can be found) becomes the responsibility of the Squeak application (or
its developers/installers.)  The problem of choosing which Olson timezone
should be contained in /etc/localtime (or its equivalent on a non-Unix box)
remains.

Correct me if I'm wrong, but I believe that it's that problem--how to know
which time zone rule set represents local time--that is the topic of this
conversation.

After all, I already knew about your TimeZoneDatabase package when I posted
above, just as you already knew about the Chronos Date/Time Library (of which I
am the author,) which is also available for Squeak, and also solves all the
same problems as does TimeZoneDatabase. I didn't mention either of them, for
two reasons:  1) Both must be installed, and don't come "out of the box" with
Squeak, and 2) the Squeak version of Chronos (unlike the VisualWorks and
Dolphin versions) is not able to use the operating system to determine which
Olson time zone represents local time, and the TimeZoneDatabase can only do so
on some Unixes.

And, now that I know of the Locale package, I would like to enhance the Squeak
version of Chronos so that it will be able to determine the almost-certainly-
correct Olson timezone for local time on any platform for which the Locale
package is implemented.

I also would like to leverage your TimeZoneDatabase code in Chronos, so that
Chronos can read binary tzfiles, and especially so that it can read /etc/
localtime, if that file is available on the Unix box on which Chronos is being
used.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michael Rueger <m.rueger <at> acm.org> writes:

>
> Alan Lovejoy wrote:
>
> > Well, that's better than nothing--although "experimental" code (that's not
well
> > known, isn't installed by default, and may not work on all platforms) just
> > doesn't make the grade.
>
> Feel free to add the required functionality, it's OpenSource, you know...

Funny you should mention that, because in a way, I in fact have solved this
problem (i.e., how to determine which time zone ruleset represents local
time.)  I am the author of the Chronos Date/Time Library, which is available
for Squeak [http://www.chronos-st.org].

The VisualWorks version of Chronos can figure out which Olson timezone best
represents local time, based on information provided by the operating system.
It can do this in several ways:

1) By reading the value of the TZ environment variable (Unix, MacOSX or
Windows.)
2) By reading the time zone ruleset out of the Windows registry. [The Dolphin
version of Chronos also does this.]
3) By finding the most likely/best match to an Olson timezome based on both the
current sytem timezone offset and the system country code.

Note item 3.  The Squeak version of Chronos should be able to use the Locale
package to do the same thing in Squeak. I intend to add that enhancement to
Chronos.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2006/12/17, Alan Lovejoy <[hidden email]>:
Hi

Sorry for hijacking this thread but I have a Chronos question:
Is there a way to create ScientificDuration from a String?
I'm talking about a round trip like
Timepoint readFrom: Timepoint now printString readStream
for ScientificDuration durations.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall <philippe.marschall <at> gmail.com> writes:
Unfortunately, not yet.  There is code that almost does that, but not quite.  
That code creates a TimeOfDay from a String: "ChronosParser default
nextTimeOfDayFrom: '23:59:59' readStream."  

I will be releasing a new version of Chronos that will implement parsing for
ScientificDurations and CivilDurations. At least initially, I will probably
only support the ANSI format for ScientificDurations ("202:14:07:22.105538")
and the ISO8601 format for CivilDurations ("202d14h7m22.105538s".)





_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Sun, Dec 17, 2006 at 06:51:18AM +0000, Alan Lovejoy wrote:
Thanks Alan, let me know if I can help or if you need any utility methods
to e.g. load /etc/localtime directly.

Dave

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2006/12/17, Alan Lovejoy <[hidden email]>:
This is good news. I'm looking for ward to this version.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside