Smalltalk › Squeak › Squeak - Dev

trunk thinks its tomorrow

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

Chris Muller-3

trunk thinks its tomorrow

Date today and DateAndTime now are reporting tomorrow's date instead
of today's. Ouch!

DateAndTime now " 2016-02-16T03:16:25.421108-06:00"

That's my timezone offset. But its still Monday, the 15th, not the 16th..

timrowledge

Re: trunk thinks its tomorrow

> On 15-02-2016, at 7:17 PM, Chris Muller <[hidden email]> wrote:
>
> Date today and DateAndTime now are reporting tomorrow's date instead
> of today's. Ouch!
>
> DateAndTime now " 2016-02-16T03:16:25.421108-06:00"
>
> That's my timezone offset. But its still Monday, the 15th, not the 16th..
>
Hmph. Checking on my Pi I get a completely wrong TZ because my preference ‘useLocale’ is false. The code in Locale>startUp: dates back to 2005/8 so it’s unlikely to be wrong without having been noticed.

Hmm, even weirder - it’s not a preference I screwed up so far as I can tell since it is the same in a plain 5.0 image on my iMac. Which makes me wonder why the menubar time is correct…

Oh yuck. DateAndTime>now uses nowWithOffset: and the (wrong) offset. The ClockMorph uses Time>now which works from millisecondsSinceMidnight and uses the old prim 135 millisecond clock in an original 5.0 image and localMicrosecondClock in a recent update. So the TZ is getting added at the primitive level and we have confusion. Is it really a good idea to have a primitive using the OS idea of TZ as well as image code using its own idea of TZ?

The net effect with latest updates installed is -
DateAndTime now 2016-02-16T18:56:54.67808+01:00
Time now 10:56:51.64374 am

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Do files get embarrassed when they get unzipped?

Chris Muller-3

Re: trunk thinks its tomorrow

The problem has nothing to do with timezones or offsets. Those
haven't changed in several years. Try printing "Date today" in a
Squeak 5.0 release image, then update it to latest trunk, and print it
again. They don't match.

I think this is probably related to the new utcMicrosecond clock stuff.

On Tue, Feb 16, 2016 at 1:00 PM, tim Rowledge <[hidden email]> wrote:

>
>> On 15-02-2016, at 7:17 PM, Chris Muller <[hidden email]> wrote:
>>
>> Date today and DateAndTime now are reporting tomorrow's date instead
>> of today's. Ouch!
>>
>> DateAndTime now " 2016-02-16T03:16:25.421108-06:00"
>>
>> That's my timezone offset. But its still Monday, the 15th, not the 16th..
>>
> Hmph. Checking on my Pi I get a completely wrong TZ because my preference ‘useLocale’ is false. The code in Locale>startUp: dates back to 2005/8 so it’s unlikely to be wrong without having been noticed.
>
> Hmm, even weirder - it’s not a preference I screwed up so far as I can tell since it is the same in a plain 5.0 image on my iMac. Which makes me wonder why the menubar time is correct…
>
> Oh yuck. DateAndTime>now uses nowWithOffset: and the (wrong) offset. The ClockMorph uses Time>now which works from millisecondsSinceMidnight and uses the old prim 135 millisecond clock in an original 5.0 image and localMicrosecondClock in a recent update. So the TZ is getting added at the primitive level and we have confusion. Is it really a good idea to have a primitive using the OS idea of TZ as well as image code using its own idea of TZ?
>
> The net effect with latest updates installed is -
> DateAndTime now 2016-02-16T18:56:54.67808+01:00
> Time now 10:56:51.64374 am
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Do files get embarrassed when they get unzipped?
>
>
>

timrowledge

Re: trunk thinks its tomorrow

We can see the primitives involved with this do it -
{SystemNavigation default browseMessageList: #(
'Time class primMicrosecondClock 117'
'Time class primMillisecondClock 135’
'Time class eventMillisecondClock 135’
'Time class primPosixMicrosecondClockWithOffset 117’
'Time class primUTCMicrosecondClock 240’
'Time class localMicrosecondClock 241’
'Time class utcMicrosecondClock 240’
'Time class primSecondsClock 137’
'Time class primMillisecondClockMask 117’
'Time class primLocalMicrosecondClock 241') name: 'time prims’}

a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
b) primMillisecondClock/135 is not sent in a 5.0 image
c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
d) primPosixMicrosecondClockWithOffset is not sent in 5.0
e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
h) primSecondsClock/137 isn’t used in 5.0
i) primMillisecondClockMask isn’t used in 5.0
j) primLocalMicrosecondClock/241 isn’t used in 5.0

So we have quite a collection of mixedup terminology and unused methods to clear up!

Looking at it from the prims point of view -

Prim 135 is needed in order to provide the same timebase as the events coming in, so we can’t drop that, and it affects nothing else.

Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.

The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood?

David T. Lewis

Re: trunk thinks its tomorrow

In reply to this post by Chris Muller-3

On Tue, Feb 16, 2016 at 10:05:06PM -0600, Chris Muller wrote:

>
> On Tue, Feb 16, 2016 at 1:00 PM, tim Rowledge <[hidden email]> wrote:
> >
> >> On 15-02-2016, at 7:17 PM, Chris Muller <[hidden email]> wrote:
> >>
> >> Date today and DateAndTime now are reporting tomorrow's date instead
> >> of today's. Ouch!
> >>
> >> DateAndTime now " 2016-02-16T03:16:25.421108-06:00"
> >>
> >> That's my timezone offset. But its still Monday, the 15th, not the 16th..
> >>
> > Hmph. Checking on my Pi I get a completely wrong TZ because my preference
> > ???useLocale??? is false. The code in Locale>startUp: dates back to 2005/8
> > so it???s unlikely to be wrong without having been noticed.
> >
> > Hmm, even weirder - it???s not a preference I screwed up so far as I can
> > tell since it is the same in a plain 5.0 image on my iMac. Which makes me
> > wonder why the menubar time is correct???
> >
> > Oh yuck. DateAndTime>now uses nowWithOffset: and the (wrong) offset. The
> > ClockMorph uses Time>now which works from millisecondsSinceMidnight and
> > uses the old prim 135 millisecond clock in an original 5.0 image and
> > localMicrosecondClock in a recent update. So the TZ is getting added at
> > the primitive level and we have confusion. Is it really a good idea to
> > have a primitive using the OS idea of TZ as well as image code using its
> > own idea of TZ?
> >
> > The net effect with latest updates installed is -
> > DateAndTime now 2016-02-16T18:56:54.67808+01:00
> > Time now 10:56:51.64374 am
> >
> >
> The problem has nothing to do with timezones or offsets. Those
> haven't changed in several years. Try printing "Date today" in a
> Squeak 5.0 release image, then update it to latest trunk, and print it
> again. They don't match.
>
> I think this is probably related to the new utcMicrosecond clock stuff.
>

Well this is a fine kettle of fish (http://www.phrases.org.uk/meanings/kettle-of-fish.html).

At first glance, the problem seems to be that with the UTC time changes,
'DateAndTime now' requires a time zone. If you enable preference #useLocale,
the system is supposed to figure out a time zone from 'Locale current'.
That in turn depends on the LocalPlugin, which does seem to be present.

But I see that the primitive methods in Local are working, so the
uninitialized instance vars are a red herring, which I will toss into the
kettle of fish for later consideration.

As a workaround, I was going to suggest setting the TimeZone class variable
in DateAndTime to something that represents your local time zone offset.
For me, this would be:

DateAndTime localTimeZone: (TimeZone
offset: -4 hours
name: 'Eastern Daylight Time'
abbreviation: 'EDT')

But it looked like that the offset is bass-ackwards, so I did this instead:

DateAndTime localTimeZone: (TimeZone
offset: 4 hours
name: 'Eastern Daylight Time'
abbreviation: 'EDT')

Oops, that that does not work either. Apparently the time zone offset is
going into the bit bucket.

It seems that we currently have a mashup of things in Chronology that
assume that the system reports time in local wall clock time (which is
and always has been horrible), plus recent updates that do some things
in location-independent UTC (good, but not yet working right).

I will post an update to DataAndTime class>>nowWithOffset that seems to
me to be the LHTTCPW (least horrible thing that could possibly work).

Dave

David T. Lewis

Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

In reply to this post by timrowledge

I would like to move Chronology from 'Kernel-Chronology' to a new package
called 'Chronology', and move 'KernelTests-Chronology' to a new package
called 'Tests-Chronology'.

Rationale:

- Chronology is a large package that is functionally separable from the
rest of the things in Kernel.

- I have a UTC based variation of Chronology that addresses a number of
issues that I think may be of long term benefit, and that prevent the kinds
of issues that we are currently seeing in trunk. I would like to offer this
for review in the inbox, but that is not practical with the current
packaging.

Would anyone object to this change to package structure?

Thanks,
Dave

On Wed, Feb 17, 2016 at 05:13:05PM -0800, tim Rowledge wrote:

> We can see the primitives involved with this do it -
> {SystemNavigation default browseMessageList: #(
> 'Time class primMicrosecondClock 117'
> 'Time class primMillisecondClock 135???
> 'Time class eventMillisecondClock 135???
> 'Time class primPosixMicrosecondClockWithOffset 117???
> 'Time class primUTCMicrosecondClock 240???
> 'Time class localMicrosecondClock 241???
> 'Time class utcMicrosecondClock 240???
> 'Time class primSecondsClock 137???
> 'Time class primMillisecondClockMask 117???
> 'Time class primLocalMicrosecondClock 241') name: 'time prims???}
>
> a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
> b) primMillisecondClock/135 is not sent in a 5.0 image
> c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
> d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
> f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
> g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
> h) primSecondsClock/137 isn???t used in 5.0
> i) primMillisecondClockMask isn???t used in 5.0
> j) primLocalMicrosecondClock/241 isn???t used in 5.0
>
> So we have quite a collection of mixedup terminology and unused methods to clear up!
>
> Looking at it from the prims point of view -
>
> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can???t drop that, and it affects nothing else.
>
> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
>
> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood?
>
>

timrowledge

Re: trunk thinks its tomorrow

In reply to this post by David T. Lewis

> On 17-02-2016, at 5:15 PM, David T. Lewis <[hidden email]> wrote:
>

> I will post an update to DataAndTime class>>nowWithOffset that seems to
> me to be the LHTTCPW (least horrible thing that could possibly work).

Ah sorry Dave, you can’t do that (as in http://source.squeak.org/trunk/Kernel-dtl.990.mcz)

The code is working ok if the TZ is set correctly. If I set PST
DateAndTime localTimeZone: (TimeZone offset: -8 hours name: 'Pacific Standard Time' abbreviation: 'PST’).
then
DateAndTime now -> 2016-02-18T01:30:48.40668-08:00
which is correct - the UTC is 8 hrs ahead of my local time.

Now, ‘DateAndTime now asLocal’ seems to me to be wrong since it returns just the same time. And asUTC appears to go the wrong way, showing it to be 9:30 in the morning

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BYEBYE: Store in Write-Only Storage

David T. Lewis

Re: trunk thinks its tomorrow

On Wed, Feb 17, 2016 at 05:35:45PM -0800, tim Rowledge wrote:

>
> > On 17-02-2016, at 5:15 PM, David T. Lewis <[hidden email]> wrote:
> >
>
> > I will post an update to DataAndTime class>>nowWithOffset that seems to
> > me to be the LHTTCPW (least horrible thing that could possibly work).
>
> Ah sorry Dave, you can???t do that (as in http://source.squeak.org/trunk/Kernel-dtl.990.mcz)
>
> The code is working ok if the TZ is set correctly. If I set PST
> DateAndTime localTimeZone: (TimeZone offset: -8 hours name: 'Pacific Standard Time' abbreviation: 'PST???).
> then
> DateAndTime now -> 2016-02-18T01:30:48.40668-08:00
> which is correct - the UTC is 8 hrs ahead of my local time.

Since introduction of the UTC changes, none of this is going to work
without the time zone being set. So if you set your time zone and it
seems to work, that is good. Or at least it is less horrible than
before.

>
> Now, ???DateAndTime now asLocal??? seems to me to be wrong since it returns just the same time. And asUTC appears to go the wrong way, showing it to be 9:30 in the morning
>

Dunno. There is no method comment for DateAndTime>>asLocal. I would
expect it to answer an instance that represents the same absolute time,
but with with the offset set to local time zone and other instance
variables set to make it look like the same time. It does seem to be
doing this.

This also seems to do what I would expect:

now := DateAndTime now.
{ now . now asUTC asLocal } ==> {2016-02-17T21:06:53.482839-05:00 . 2016-02-17T21:06:53.482839-05:00}

Dave

Bert Freudenberg

Re: trunk thinks its tomorrow

> On 17.02.2016, at 18:11, David T. Lewis <[hidden email]> wrote:
>
> On Wed, Feb 17, 2016 at 05:35:45PM -0800, tim Rowledge wrote:
>>
>>> On 17-02-2016, at 5:15 PM, David T. Lewis <[hidden email]> wrote:
>>>
>>
>>> I will post an update to DataAndTime class>>nowWithOffset that seems to
>>> me to be the LHTTCPW (least horrible thing that could possibly work).
>>
>> Ah sorry Dave, you can???t do that (as in http://source.squeak.org/trunk/Kernel-dtl.990.mcz)
>>
>> The code is working ok if the TZ is set correctly. If I set PST
>> DateAndTime localTimeZone: (TimeZone offset: -8 hours name: 'Pacific Standard Time' abbreviation: 'PST???).
>> then
>> DateAndTime now -> 2016-02-18T01:30:48.40668-08:00
>> which is correct - the UTC is 8 hrs ahead of my local time.
>
> Since introduction of the UTC changes, none of this is going to work
> without the time zone being set. So if you set your time zone and it
> seems to work, that is good. Or at least it is less horrible than
> before.
>
>>
>> Now, ???DateAndTime now asLocal??? seems to me to be wrong since it returns just the same time. And asUTC appears to go the wrong way, showing it to be 9:30 in the morning
>>
>
> Dunno. There is no method comment for DateAndTime>>asLocal. I would
> expect it to answer an instance that represents the same absolute time,
> but with with the offset set to local time zone and other instance
> variables set to make it look like the same time. It does seem to be
> doing this.
>
> This also seems to do what I would expect:
>
> now := DateAndTime now.
> { now . now asUTC asLocal } ==> {2016-02-17T21:06:53.482839-05:00 . 2016-02-17T21:06:53.482839-05:00}
>
> Dave

I committed a more invasive “fix”. Looking forward to your overhaul!

- Bert -

smime.p7s (5K) Download Attachment

Bert Freudenberg

Re: trunk thinks its tomorrow

> I committed a more invasive “fix”. Looking forward to your overhaul!

Btw, I discovered that utcMicrosecondClock differs from primPosixMicrosecondClockWithOffset - the VM must use a different way to get its time. I worked around that by not using the non-offset prims at all, but it may lead to problems.

In any case, the image now automatically uses the OS’s time zone as reported by primPosixMicrosecondClockWithOffset. To make the tests green I had to make TimeSpan comparison more lenient (treating defaultOffset as wildcard). Basically, if a Date has no timezone set then it will match a Date in any time zone as long as they “look” the same. Possibly a better idea would be to have different classes for dates with and without timezones, but then that may be even more confusing.

I did not remove the timezone handling in Locale startup yet, although it is useless now.

- Bert -

smime.p7s (5K) Download Attachment

Bert Freudenberg

Re: trunk thinks its tomorrow

In reply to this post by timrowledge

> On 17.02.2016, at 17:13, tim Rowledge <[hidden email]> wrote:
>
> a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
> b) primMillisecondClock/135 is not sent in a 5.0 image
> c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
> d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
> f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
> g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
> h) primSecondsClock/137 isn’t used in 5.0
> i) primMillisecondClockMask isn’t used in 5.0
> j) primLocalMicrosecondClock/241 isn’t used in 5.0
>
> So we have quite a collection of mixedup terminology and unused methods to clear up!
>
> Looking at it from the prims point of view -
>
> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can’t drop that, and it affects nothing else.
>
> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
>
> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.

I think we should go back to prim 135 for millisecondClockValue (or maybe possibly derive it from prim 240).

Time now should use primPosixMicrosecondClockWithOffset to be exactly equivalent to what DateAndTime now does. (unless the VM is fixed to use the exact same mechanism for both) Even better would be a localMicrosecondClockWithOffset primitive that could do that method’s work without LargeInt arithmetic.

- Bert -

smime.p7s (5K) Download Attachment

David T. Lewis

Re: trunk thinks its tomorrow

In reply to this post by Bert Freudenberg

On Wed, Feb 17, 2016 at 06:49:03PM -0800, Bert Freudenberg wrote:
> > I committed a more invasive ???fix???. Looking forward to your overhaul!
>
> Btw, I discovered that utcMicrosecondClock differs from primPosixMicrosecondClockWithOffset - the VM must use a different way to get its time. I worked around that by not using the non-offset prims at all, but it may lead to problems.
>
> In any case, the image now automatically uses the OS???s time zone as reported by primPosixMicrosecondClockWithOffset. To make the tests green I had to make TimeSpan comparison more lenient (treating defaultOffset as wildcard). Basically, if a Date has no timezone set then it will match a Date in any time zone as long as they ???look??? the same. Possibly a better idea would be to have different classes for dates with and without timezones, but then that may be even more confusing.
>

I think that all we really need is a clear definition of whether DateAndTime
represents local wall clock time, or location-independent time. I think that
it needs to represent location-independent time, and that we should define
it as such. The instance variables in DateAndTime make this a bit obscure,
but if the value of the absolute time and the value of the local time zone
offset are kept separate, it becomes less confusing. That is what I tried to
do in http://wiki.squeak.org/squeak/6197

> I did not remove the timezone handling in Locale startup yet, although it is useless now.
>
> - Bert -
>

This looks good to me.

I like the automatic time zone offset update in DateAndTime>>now.

For primPosixMicrosecondClockWithOffset, we probably should have fallback code
that calls <primitive 135> primMillisecondClock for VMs that support only the
original millisecond clock primitive.

Dave

David T. Lewis

Re: trunk thinks its tomorrow

In reply to this post by Bert Freudenberg

On Wed, Feb 17, 2016 at 06:56:58PM -0800, Bert Freudenberg wrote:

>
> > On 17.02.2016, at 17:13, tim Rowledge <[hidden email]> wrote:
> >
> > a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
> > b) primMillisecondClock/135 is not sent in a 5.0 image
> > c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
> > d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> > e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
> > f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
> > g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
> > h) primSecondsClock/137 isn???t used in 5.0
> > i) primMillisecondClockMask isn???t used in 5.0
> > j) primLocalMicrosecondClock/241 isn???t used in 5.0
> >
> > So we have quite a collection of mixedup terminology and unused methods to clear up!
> >
> > Looking at it from the prims point of view -
> >
> > Prim 135 is needed in order to provide the same timebase as the events coming in, so we can???t drop that, and it affects nothing else.
> >
> > Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
> > Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
> >
> > The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
>
> I think we should go back to prim 135 for millisecondClockValue (or maybe possibly derive it from prim 240).

All other things equal, I would think it is better to use prim 135 because
that has been a required primitive all along.

>
> Time now should use primPosixMicrosecondClockWithOffset to be exactly equivalent to what DateAndTime now does. (unless the VM is fixed to use the exact same mechanism for both) Even better would be a localMicrosecondClockWithOffset primitive that could do that method???s work without LargeInt arithmetic.
>

In the limited testing that I have done, the use of large integers as
return values for time primitives make very little difference. And with
the Spur object format, it becomes irrelevant. So I don't think we need
to worry about that.

Dave

Eliot Miranda-2

Re: trunk thinks its tomorrow

In reply to this post by Bert Freudenberg

Hi Bert,

> On Feb 17, 2016, at 6:56 PM, Bert Freudenberg <[hidden email]> wrote:
>
>
>> On 17.02.2016, at 17:13, tim Rowledge <[hidden email]> wrote:
>>
>> a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
>> b) primMillisecondClock/135 is not sent in a 5.0 image
>> c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
>> d) primPosixMicrosecondClockWithOffset is not sent in 5.0
>> e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
>> f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
>> g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
>> h) primSecondsClock/137 isn’t used in 5.0
>> i) primMillisecondClockMask isn’t used in 5.0
>> j) primLocalMicrosecondClock/241 isn’t used in 5.0
>>
>> So we have quite a collection of mixedup terminology and unused methods to clear up!
>>
>> Looking at it from the prims point of view -
>>
>> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can’t drop that, and it affects nothing else.
>>
>> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
>> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
>>
>> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
>
> I think we should go back to prim 135 for millisecondClockValue (or maybe possibly derive it from prim 240).

I like the idea of deriving it. Having reliance in the old prim seems weak to me. Logically the milliseconds since startup can be derived from microseconds. The latest VMs answer the value of the utcMicrosecondClock at start up via vmParameterAt: N (can't remember N). So in eg Delay startUp: the system could query the utcMicrosecondClock at start up via vmParameterAt and if the query fails just use utcMicrosecondClock now and store this in a variable and answer the millisecond clock by subtracting this from utcMicrosecondClock.

In new VMs I can also make the event time stamps agree with this.

>
> Time now should use primPosixMicrosecondClockWithOffset to be exactly equivalent to what DateAndTime now does. (unless the VM is fixed to use the exact same mechanism for both) Even better would be a localMicrosecondClockWithOffset primitive that could do that method’s work without LargeInt arithmetic.

I wish David had never introduced this. The Smalltalk epoch is fine. Why do we need other than utcMicrosecondClock and localMicrosecondClock? We can derive posix times from utcMicrosecondClock trivially. There is some concern about the cost of large integer arithmetic but in practice the cost is negligible because the system spends tiny amounts of time computing times and lots of time doing useful stuff in between.

>
> - Bert -
>
>
>
>

Bert Freudenberg

Re: trunk thinks its tomorrow

> On 17.02.2016, at 20:10, Eliot Miranda <[hidden email]> wrote:

>
> Hi Bert,
>
>> On Feb 17, 2016, at 6:56 PM, Bert Freudenberg <[hidden email]> wrote:
>>
>>
>>> On 17.02.2016, at 17:13, tim Rowledge <[hidden email]> wrote:
>>>
>>>
>>> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can’t drop that, and it affects nothing else.
>>>
>>> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
>>> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
>>>
>>> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
>>
>> I think we should go back to prim 135 for millisecondClockValue (or maybe possibly derive it from prim 240).
>
> I like the idea of deriving it. Having reliance in the old prim seems weak to me. Logically the milliseconds since startup can be derived from microseconds. The latest VMs answer the value of the utcMicrosecondClock at start up via vmParameterAt: N (can't remember N). So in eg Delay startUp: the system could query the utcMicrosecondClock at start up via vmParameterAt and if the query fails just use utcMicrosecondClock now and store this in a variable and answer the millisecond clock by subtracting this from utcMicrosecondClock.
>
> In new VMs I can also make the event time stamps agree with this.

Sounds good.

>>
>> Time now should use primPosixMicrosecondClockWithOffset to be exactly equivalent to what DateAndTime now does. (unless the VM is fixed to use the exact same mechanism for both) Even better would be a localMicrosecondClockWithOffset primitive that could do that method’s work without LargeInt arithmetic.
>
> I wish David had never introduced this. The Smalltalk epoch is fine. Why do we need other than utcMicrosecondClock and localMicrosecondClock? We can derive posix times from utcMicrosecondClock trivially. There is some concern about the cost of large integer arithmetic but in practice the cost is negligible because the system spends tiny amounts of time computing times and lots of time doing useful stuff in between.

It's not about the time base (Smalltalk would be preferable indeed) but an atomic call giving current time and offset. As I wrote, localMicrosecondClockWithOffset would be ideal.

- Bert -

smime.p7s (8K) Download Attachment

marcel.taeumel

Re: trunk thinks its tomorrow

Hi, there!

The VM seems to "cache" the wall clock. This is weird.

Here is the story: I just booted into Windows and my time was wrong. Seems to be come Surface bug. It still was at the sleep time yesterday evenening, 11pm.

Squeak was already open, reporting the same.

Then, I updated the system time by letting Windows sync with Microsofts time server.

And then, the still running Squeak VM reported still the old values!!! :-/ How can that happen?

Best,
Marcel

Nicolas Cellier

Re: Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

In reply to this post by David T. Lewis

Why not ChronologyTests?

2016-02-18 2:33 GMT+01:00 David T. Lewis <[hidden email]>:

I would like to move Chronology from 'Kernel-Chronology' to a new package
called 'Chronology', and move 'KernelTests-Chronology' to a new package
called 'Tests-Chronology'.

Rationale:

- Chronology is a large package that is functionally separable from the
rest of the things in Kernel.

- I have a UTC based variation of Chronology that addresses a number of
issues that I think may be of long term benefit, and that prevent the kinds
of issues that we are currently seeing in trunk. I would like to offer this
for review in the inbox, but that is not practical with the current
packaging.

Would anyone object to this change to package structure?

Thanks,
Dave

On Wed, Feb 17, 2016 at 05:13:05PM -0800, tim Rowledge wrote:
> We can see the primitives involved with this do it -
> {SystemNavigation default browseMessageList: #(
> 'Time class primMicrosecondClock 117'
> 'Time class primMillisecondClock 135???
> 'Time class eventMillisecondClock 135???
> 'Time class primPosixMicrosecondClockWithOffset 117???
> 'Time class primUTCMicrosecondClock 240???
> 'Time class localMicrosecondClock 241???
> 'Time class utcMicrosecondClock 240???
> 'Time class primSecondsClock 137???
> 'Time class primMillisecondClockMask 117???
> 'Time class primLocalMicrosecondClock 241') name: 'time prims???}
>
> a) primMicrosecondClock is not sent in a 5.0 image and seems to only be implemented in a plain interpreter VM.
> b) primMillisecondClock/135 is not sent in a 5.0 image
> c) eventMillisecondClock/135 is used for the faked-up events required for double-click handling
> d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec value in raw
> f) localMicrosecondClock/241 is used in 5.0 in particular from Time now (as per the ClockMorph)
> g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type cases
> h) primSecondsClock/137 isn???t used in 5.0
> i) primMillisecondClockMask isn???t used in 5.0
> j) primLocalMicrosecondClock/241 isn???t used in 5.0
>
> So we have quite a collection of mixedup terminology and unused methods to clear up!
>
> Looking at it from the prims point of view -
>
> Prim 135 is needed in order to provide the same timebase as the events coming in, so we can???t drop that, and it affects nothing else.
>
> Prim 240 is for no-TZ microseconds and is used in Delay etc but crucially as part of DateAndTime>now which is why we are having a problem in the latest updated 5.0 with no TZ/Locale being used.
> Prim 241 is used by Time now etc and includes the TZ offset, which is why Time now returns correct wall-clock time.
>
> The others are no longer used and could be removed except for the primPosixMicrosecondClockWithOffset which we ought to make use of so that the TZ is reported back.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari? = How much wood would a woodchuck chuck if a woodchuck could chuck wood?
>
>

David T. Lewis

Re: Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

On Thu, Feb 18, 2016 at 12:18:18PM +0100, Nicolas Cellier wrote:
> Why not ChronologyTests?

Agreed, that would be better.

Dave

>
> 2016-02-18 2:33 GMT+01:00 David T. Lewis <[hidden email]>:
>
> > I would like to move Chronology from 'Kernel-Chronology' to a new package
> > called 'Chronology', and move 'KernelTests-Chronology' to a new package
> > called 'Tests-Chronology'.
> >
> > Rationale:
> >
> > - Chronology is a large package that is functionally separable from the
> > rest of the things in Kernel.
> >
> > - I have a UTC based variation of Chronology that addresses a number of
> > issues that I think may be of long term benefit, and that prevent the kinds
> > of issues that we are currently seeing in trunk. I would like to offer this
> > for review in the inbox, but that is not practical with the current
> > packaging.
> >
> > Would anyone object to this change to package structure?
> >
> > Thanks,
> > Dave
> >
> >
> > On Wed, Feb 17, 2016 at 05:13:05PM -0800, tim Rowledge wrote:
> > > We can see the primitives involved with this do it -
> > > {SystemNavigation default browseMessageList: #(
> > > 'Time class primMicrosecondClock 117'
> > > 'Time class primMillisecondClock 135???
> > > 'Time class eventMillisecondClock 135???
> > > 'Time class primPosixMicrosecondClockWithOffset 117???
> > > 'Time class primUTCMicrosecondClock 240???
> > > 'Time class localMicrosecondClock 241???
> > > 'Time class utcMicrosecondClock 240???
> > > 'Time class primSecondsClock 137???
> > > 'Time class primMillisecondClockMask 117???
> > > 'Time class primLocalMicrosecondClock 241') name: 'time prims???}
> > >
> > > a) primMicrosecondClock is not sent in a 5.0 image and seems to only be
> > implemented in a plain interpreter VM.
> > > b) primMillisecondClock/135 is not sent in a 5.0 image
> > > c) eventMillisecondClock/135 is used for the faked-up events required
> > for double-click handling
> > > d) primPosixMicrosecondClockWithOffset is not sent in 5.0
> > > e) primUTCMicrosecondClock/240 is not sent in 5.0 - would return uSec
> > value in raw
> > > f) localMicrosecondClock/241 is used in 5.0 in particular from Time now
> > (as per the ClockMorph)
> > > g) utcMicrosecondClock/240 is used in 5.0 for Delays and timing type
> > cases
> > > h) primSecondsClock/137 isn???t used in 5.0
> > > i) primMillisecondClockMask isn???t used in 5.0
> > > j) primLocalMicrosecondClock/241 isn???t used in 5.0
> > >
> > > So we have quite a collection of mixedup terminology and unused methods
> > to clear up!
> > >
> > > Looking at it from the prims point of view -
> > >
> > > Prim 135 is needed in order to provide the same timebase as the events
> > coming in, so we can???t drop that, and it affects nothing else.
> > >
> > > Prim 240 is for no-TZ microseconds and is used in Delay etc but
> > crucially as part of DateAndTime>now which is why we are having a problem
> > in the latest updated 5.0 with no TZ/Locale being used.
> > > Prim 241 is used by Time now etc and includes the TZ offset, which is
> > why Time now returns correct wall-clock time.
> > >
> > > The others are no longer used and could be removed except for the
> > primPosixMicrosecondClockWithOffset which we ought to make use of so that
> > the TZ is reported back.
> > >
> > > tim
> > > --
> > > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> > > Useful Latin Phrases:- Quantum materiae materietur marmota monax si
> > marmota monax materiam possit materiari? = How much wood would a woodchuck
> > chuck if a woodchuck could chuck wood?
> > >
> > >
> >
> >

Chris Muller-3

Re: Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

In reply to this post by David T. Lewis

On Wed, Feb 17, 2016 at 7:33 PM, David T. Lewis <[hidden email]> wrote:
> I would like to move Chronology from 'Kernel-Chronology' to a new package
> called 'Chronology', and move 'KernelTests-Chronology' to a new package
> called 'Tests-Chronology'.
>
> Rationale:
>
> - Chronology is a large package that is functionally separable from the
> rest of the things in Kernel.

It's not that big. It includes Date and Time, which are part of base
Smalltalk-80. How you going to extricate those from Chronology?

> - I have a UTC based variation of Chronology that addresses a number of
> issues that I think may be of long term benefit, and that prevent the kinds
> of issues that we are currently seeing in trunk. I would like to offer this
> for review in the inbox, but that is not practical with the current
> packaging.

Chronology has proved its usefulness in a wide variety of
applications. I have no issues with it. What issues are you
attempting to address with your UTC based variation?

> Would anyone object to this change to package structure?

I really think Date and Time and possibly even DateAndTime are part of
Kernel Smalltalk-80. I think it would be nice to know what it is
you're really trying to accomplish with your UTC variation..

Incidentally, if you do go down this road, the standard that most
packages following these days are hierarchical names; Chronology-Core
and Chronology-Tests.

David T. Lewis

Re: Move Chronology out of Kernel and into its own Chronology package (was: trunk thinks its tomorrow)

Hi Chris,

This was something I did last year:

http://wiki.squeak.org/squeak/6197

I would like to be able to share this so folks can review the code. I'd
prefer to be able to do that with Monticello, which is not practical with
the current package structure.

Dave

> On Wed, Feb 17, 2016 at 7:33 PM, David T. Lewis <[hidden email]>
> wrote:
>> I would like to move Chronology from 'Kernel-Chronology' to a new
>> package
>> called 'Chronology', and move 'KernelTests-Chronology' to a new package
>> called 'Tests-Chronology'.
>>
>> Rationale:
>>
>> - Chronology is a large package that is functionally separable from the
>> rest of the things in Kernel.
>
> It's not that big. It includes Date and Time, which are part of base
> Smalltalk-80. How you going to extricate those from Chronology?
>
>> - I have a UTC based variation of Chronology that addresses a number of
>> issues that I think may be of long term benefit, and that prevent the
>> kinds
>> of issues that we are currently seeing in trunk. I would like to offer
>> this
>> for review in the inbox, but that is not practical with the current
>> packaging.
>
> Chronology has proved its usefulness in a wide variety of
> applications. I have no issues with it. What issues are you
> attempting to address with your UTC based variation?
>
>> Would anyone object to this change to package structure?
>
> I really think Date and Time and possibly even DateAndTime are part of
> Kernel Smalltalk-80. I think it would be nice to know what it is
> you're really trying to accomplish with your UTC variation..
>
> Incidentally, if you do go down this road, the standard that most
> packages following these days are hierarchical names; Chronology-Core
> and Chronology-Tests.
>