Locale & TimeZones in 4.0 image

The RISC OS resurrection is going well but I'm finding some interesting issues along the way, not surprisingly.

One that puzzled me yesterday was noticing that the 'Time now' was reporting GMT without any timezone correction. I don't recall this happening 'in the old days'.

I'm more than a bit confused by the huge collection of classes handling time stuff in 4.0 but so far as I could tell it makes no use whatsoever of the Locale plugin to find out the TZ - or many other - values. In fact it was hard to spot any use at all of the Locale stuff. All the other platforms appear to be returning a local time instead of a GMT value, which puzzles me since RISC OS has been using GMT since at least v1.20 in 1997!  

Does anyone remember that changing & if os, when? I guess it's a bit of a non-issue for recent images since the 'Time now' is calculated quite differently.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- PORTE-KOCHERE - Sacramental wine

On Fri, Jan 11, 2013 at 05:20:57PM -0800, tim Rowledge wrote:
> The RISC OS resurrection is going well but I'm finding some interesting issues along the way, not surprisingly.
>
> One that puzzled me yesterday was noticing that the 'Time now' was reporting GMT without any timezone correction. I don't recall this happening 'in the old days'.
>
> I'm more than a bit confused by the huge collection of classes handling time stuff in 4.0 but so far as I could tell it makes no use whatsoever of the Locale plugin to find out the TZ - or many other - values. In fact it was hard to spot any use at all of the Locale stuff. All the other platforms appear to be returning a local time instead of a GMT value, which puzzles me since RISC OS has been using GMT since at least v1.20 in 1997!  
>
> Does anyone remember that changing & if os, when? I guess it's a bit of a non-issue for recent images since the 'Time now' is calculated quite differently.
>

The changes are in the image, and occurred fairly recently between Squeak 4.3 and 4.4.
Independently, the Pharo folks have done more extensive UTC related changes. The Pharo
changes sound like a good idea but last I checked I could not even get my TimeZoneDatabase
to work on it, so I gave up trying. The Squeak changes are IMO somewhat aesthetically
questionable but in practice are greatly beneficial to folks keeping track of time
stamps in databases and so forth, so I think practicality wins out here.

The underlying problem behind all this is that early Squeak VMs reported system
time in the local time zone rather than UTC, which may have made sense at the
time for single-user systems but is a mess if you want to do any kind of reasonable
time zone support or calculation of time durations. I'd love to throw the whole
thing out and start over with UTC throughout, but needless to say that would be
a non-trivial amount of work.

To find the changes, use Monticello to look in source.squeak.org/trunk in the
Kernel package (click the "history" button for a quick view). The relevant changes
were introduced in Kernel-cmm.672, Kernel-cmm.671, Kernel-cmm.670, and Kernel-cmm.669.
There was discussion about it on squeak-dev in that same time frame.

Here are two Monticello update comments that give a good summary of the changes:

    Name: Kernel-cmm.669
    Author: cmm
    Time: 3 February 2012, 5:55:11.175 pm
    UUID: 5ddec343-01ad-4e76-b32c-299fac68ec09
    Ancestors: Kernel-eem.668
   
    Introduced Timespan class>>defaultOffset.  This is the offset that will be
    used for creation of all Timespans when an offset is not specified.  When
    an offset is specified or involved in construction or calculation, the result
    is now produced in terms of the source offset.
   
    For example, Date today now produces a globalized date by default.  However,
    "Date starting: (DateAndTime year: 2004 month: 2 day: 29 hour: 13 minute:
    33 second: 0 offset: 2 hours)" produces a Date.whose start is expressed in
    terms of UTC+2.
   
    The default defaultOffset is Duration zero so that Squeak will have fast,
    globalized Dates out of the box.  Globalized Dates are common for applications.
   
    Legacy localized Dates can be obtained by evaluating "Date localize" so that,
    when an offset is not specified or otherwise involved in the input, the local
    offset will be used.
   
    Name: Kernel-cmm.671
    Author: cmm
    Time: 10 February 2012, 4:58:49.106 pm
    UUID: 9c0e18ac-1c8f-4ae6-b39e-d487720e8580
    Ancestors: Kernel-cmm.670
   
    Decided against the localized vs. globalized mode.  Timespans created in
    the context of an offset will start in that offset.  When no context is
    available, the defaultOffset for Timespans must be zero.  For example,
    two ways to make a Date for today:
    Date today.  'start is midnight at offset zero.  Will compare successfully
    to other Date today results.'
    DateAndTime now asDate.  'In this case, the start is midnight of the local
    time-zone.  It can only compare equally to Dates of its time-zone.'


Dave

On 11-01-2013, at 6:04 PM, "David T. Lewis" <[hidden email]> wrote:
>
>
> The underlying problem behind all this is that early Squeak VMs reported system
> time in the local time zone rather than UTC, which may have made sense at the
> time for single-user systems but is a mess if you want to do any kind of reasonable
> time zone support or calculation of time durations. I'd love to throw the whole
> thing out and start over with UTC throughout, but needless to say that would be
> a non-trivial amount of work.


The weird thing is that my code for ioSeconds() hasn't changed since '96 and I lived in California back then and in fact on the Wet Coast ever since 91. I don't recall ever having the time not be correct and I worked on that machine every damn day. The only story I can think of that makes any sense of it would involve RISC OS not having timezone support when I moved from the UK, me keeping the machine on PST and never taking advantage of timezone support when it arrived. I suppose it's possible.

Whatever, I guess I'll TZ ioSeconds() for now and be done with it!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
 Negligent (adj.), describes a condition in which you absentmindedly answer the door in your nightgown.

On Fri, Jan 11, 2013 at 08:56:05PM -0800, tim Rowledge wrote:
Um ... I'm a little confused myself at this point, I'm not sure what
has changed here. But I'm quite confident that in practice ioSeconds()
has been answering seconds from the "Smalltalk epoch" relative to local
time zone for a many years (probably since the first Squeak VMs). I put
that in quotes because it turns out that the Squeak definition of
Smalltalk epoch is just plain wrong. It should be this:

  DateAndTime epoch ==> 1901-01-01T00:00:00-00:00

Not this:

  DateAndTime epoch ==> 1901-01-01T00:00:00-05:00

(I am in Michigan USA, offset 5 hours from UTC)

I'll note for the record that there are now primitives that do answer
time based on UTC offset, so if you can implement ioUtcWithOffset() you
will have these:

primitiveUtcWithOffset
        "Answer an array with UTC microseconds since the Posix epoch and
        the current seconds offset from GMT in the local time zone.
        This is a named (not numbered) primitive in the null module (ie the VM)"

primitiveUTCMicrosecondClock
        "Answer the UTC microseconds since the Smalltalk epoch. The value is
        derived from the Posix epoch (see primitiveUTCMicrosecondClock) with a
        constant offset corresponding to elapsed microseconds between the two
        epochs according to RFC 868."

The first is an atomic call to obtain current time and offset relative to
Posix epoch, and the second answers seconds from the Smalltalk epoch, where
Smalltalk epoch is understood to be relative to GMT.

Dave

David T. Lewis wrote

...I put that in quotes because it turns out that the Squeak definition of
Smalltalk epoch is just plain wrong. It should be this:

  DateAndTime epoch ==> 1901-01-01T00:00:00-00:00

Not this:

  DateAndTime epoch ==> 1901-01-01T00:00:00-05:00

...

I'm in the same timezone but when I tried DateAndTime epoch, I got 1901-01-01T00:00:00+01:00. The general preference "use locale" isn't enabled in the 4.4 image (I'll add this to the 4.5 list). Timezone is stuck in Frank's locale. Tim is this causing some of your problems?

On Sat, Jan 12, 2013 at 09:02:49AM -0800, glenpaling wrote:
I also get an incorrect time zone offset if I use a fresh image:

  DateAndTime localTimeZone ==> a TimeZone(LT)

  DateAndTime localTimeZone offset ==> 0:01:00:00

  DateAndTime epoch ==> 1901-01-01T00:00:00+01:00

I didn't notice, as I normally have TimeZoneDatabase installed:

  DateAndTime localTimeZone ==> a TimeZoneProxy for America/Detroit (LMT)

  DateAndTime localTimeZone offset ==> -0:05:00:00

So perhaps there is a bug in initialization at image startup (but either
way the DateAndTime epoch is wrong).

Dave

On 12 January 2013 17:02, glenpaling <[hidden email]> wrote:
Mine would be the correct timezone :) GMT!

More seriously, the 4.4 release process doesn't fiddle with this stuff
(as far as I recall). If it does need to fiddle with this stuff, let's
put it on the 4.5 checklist.

frank

Frank Shearar-3 wrote

On 12 January 2013 17:02, glenpaling <[hidden email]> wrote:
> David T. Lewis wrote
>> ...I put that in quotes because it turns out that the Squeak definition of
>> Smalltalk epoch is just plain wrong. It should be this:
>>
>>   DateAndTime epoch ==> 1901-01-01T00:00:00-00:00
>>
>> Not this:
>>
>>   DateAndTime epoch ==> 1901-01-01T00:00:00-05:00
>>
>> ...
>
> I'm in the same timezone but when I tried DateAndTime epoch, I got
> 1901-01-01T00:00:00+01:00. The general preference "use locale" isn't enabled
> in the 4.4 image (I'll add this to the 4.5 list). Timezone is stuck in
> Frank's locale. Tim is this causing some of your problems?

Mine would be the correct timezone :) GMT!

More seriously, the 4.4 release process doesn't fiddle with this stuff
(as far as I recall). If it does need to fiddle with this stuff, let's
put it on the 4.5 checklist.

frank

Well, it's a preference, useLocale was enabled in 4.3 so something changed it on the way to 4.4. Not to point any fingers but the image is stuck in your time zone ;) The CI builds on an existing image I assume the preferences come from it. What image do you start from?

On 12-01-2013, at 6:39 AM, "David T. Lewis" <[hidden email]> wrote:

> Um ... I'm a little confused myself at this point, I'm not sure what
> has changed here. But I'm quite confident that in practice ioSeconds()
> has been answering seconds from the "Smalltalk epoch" relative to local
> time zone for a many years (probably since the first Squeak VMs).


Me too. I see the ioSeconds() code in the other platforms, I have the history of my code, I have memories of never noticing the time being wrong and I just can't make sense of it…

Anyway, I've changed my code, it reports a good time on my Pi, in a 4.0 image, so I'm content for now. Some puzzles simply aren't worth the effort of finding a complete solution-set.

I see there are some other problems with time coming up for discussion but I think I'll worry about that later when I get the next set of VM stuff working.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Virtual Memory" means never knowing where your next byte is coming from.

David T. Lewis wrote

On Sat, Jan 12, 2013 at 09:02:49AM -0800, glenpaling wrote:
> David T. Lewis wrote
> > ...I put that in quotes because it turns out that the Squeak definition of
> > Smalltalk epoch is just plain wrong. It should be this:
> >
> >   DateAndTime epoch ==> 1901-01-01T00:00:00-00:00
> >
> > Not this:
> >
> >   DateAndTime epoch ==> 1901-01-01T00:00:00-05:00
> >
> > ...
>
> I'm in the same timezone but when I tried DateAndTime epoch, I got
> 1901-01-01T00:00:00+01:00. The general preference "use locale" isn't enabled
> in the 4.4 image (I'll add this to the 4.5 list). Timezone is stuck in
> Frank's locale. Tim is this causing some of your problems?
>

I also get an incorrect time zone offset if I use a fresh image:

  DateAndTime localTimeZone ==> a TimeZone(LT)

  DateAndTime localTimeZone offset ==> 0:01:00:00

  DateAndTime epoch ==> 1901-01-01T00:00:00+01:00

I didn't notice, as I normally have TimeZoneDatabase installed:

  DateAndTime localTimeZone ==> a TimeZoneProxy for America/Detroit (LMT)

  DateAndTime localTimeZone offset ==> -0:05:00:00

So perhaps there is a bug in initialization at image startup (but either
way the DateAndTime epoch is wrong).

Dave

Not a bug, I just enabled useLocale in the preferences browser and restarted the image. Timezone initializes correctly after that.

I agree, the epoch is wrong. What would be the consequences of setting it to offset zero?

glenpaling wrote

Well, it's a preference, useLocale was enabled in 4.3

I take that back. It was also disabled in 4.3. Already been discussed: http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tt4630581.html