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..
On 15-02-2016, at 7:17 PM, Chris Muller asqueaker@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Do files get embarrassed when they get unzipped?
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 tim@rowledge.org wrote:
On 15-02-2016, at 7:17 PM, Chris Muller asqueaker@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Do files get embarrassed when they get unzipped?
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; tim@rowledge.org; 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?
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; tim@rowledge.org; 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?
Why not ChronologyTests?
2016-02-18 2:33 GMT+01:00 David T. Lewis lewis@mail.msen.com:
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; tim@rowledge.org; 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?
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 lewis@mail.msen.com:
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; tim@rowledge.org; 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?
On Wed, Feb 17, 2016 at 7:33 PM, David T. Lewis lewis@mail.msen.com 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.
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 lewis@mail.msen.com 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.
I read it, it tells me _what_ it is; a different internal representation for the Chronology classes, but I could not put together the why, as a user, I should want to use it. This is not a criticism, Dave, just ignorance. What's are the pros and cons of UTCDateAndTime approach?
On Thu, Feb 18, 2016 at 10:51 AM, David T. Lewis lewis@mail.msen.com wrote:
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 lewis@mail.msen.com 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.
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Dave
I read it, it tells me _what_ it is; a different internal representation for the Chronology classes, but I could not put together the why, as a user, I should want to use it. This is not a criticism, Dave, just ignorance. What's are the pros and cons of UTCDateAndTime approach?
On Thu, Feb 18, 2016 at 10:51 AM, David T. Lewis lewis@mail.msen.com wrote:
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 lewis@mail.msen.com 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.
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I'm a heavy user of Chronology, if there's a better version of it, I'm definitely interested in possibly using it. I remember that thread; it helped us identify and fix a performance bug in standard Chronology.
On Thu, Feb 18, 2016 at 11:30 AM, David T. Lewis lewis@mail.msen.com wrote:
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Dave
I read it, it tells me _what_ it is; a different internal representation for the Chronology classes, but I could not put together the why, as a user, I should want to use it. This is not a criticism, Dave, just ignorance. What's are the pros and cons of UTCDateAndTime approach?
On Thu, Feb 18, 2016 at 10:51 AM, David T. Lewis lewis@mail.msen.com wrote:
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 lewis@mail.msen.com 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.
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem).
So it should be this:
Chronology-Core Chronology-Tests
Instead of this:
Chronology ChronologyTests
Is that right?
I'll be curious whether you choose to move Date and Time too..
Yes. I mean that everything that was in 'Kernel-Chronology' will now be in 'Chronology' or 'Chronology-Core'.
Dave
Yes. I mean that everything that was in 'Kernel-Chronology' will now be in 'Chronology' or 'Chronology-Core'.
So we will not be able to make a kernel image that does not include some flavor of Chronology then...
On Thu, Feb 18, 2016 at 11:59 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem).
So it should be this:
Chronology-Core Chronology-Tests
Instead of this:
Chronology ChronologyTests
Is that right?
I'll be curious whether you choose to move Date and Time too..
Yes. I mean that everything that was in 'Kernel-Chronology' will now be in 'Chronology' or 'Chronology-Core'.
Dave
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I need some guidance on package naming.
We have packages named 'Kernel' and 'KernelTests', 'Morphic' and 'MorphicTests', and 'Collections' and 'CollectionsTests'. Based on this, I would expect that 'Chronology' and 'ChronologyTests' would be good package names.
Is that right? Or should it instead be 'Chronology-Core' and 'Chronology-Tests'?
Thanks,
Dave
On Sat, Feb 20, 2016 at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I need some guidance on package naming.
We have packages named 'Kernel' and 'KernelTests', 'Morphic' and 'MorphicTests', and 'Collections' and 'CollectionsTests'. Based on this, I would expect that 'Chronology' and 'ChronologyTests' would be good package names.
Is that right? Or should it instead be 'Chronology-Core' and 'Chronology-Tests'?
Note we also have packages named Regex-Core, Regex-Tests, SqueakSSL-Core, SqueakSSL-Tests, WebClient-Core, WebClient-Tests, which were (formerly) external packages. You want to make Chronology more like an external package, so it can be swapped out more easily.
"-Core" brings a clarity to the core unit's modular boundary, while being consistent with the number of levels in each package name that comprises that system.
On 21.02.2016, at 10:36, Chris Muller asqueaker@gmail.com wrote:
On Sat, Feb 20, 2016 at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I need some guidance on package naming.
We have packages named 'Kernel' and 'KernelTests', 'Morphic' and 'MorphicTests', and 'Collections' and 'CollectionsTests'. Based on this, I would expect that 'Chronology' and 'ChronologyTests' would be good package names.
Is that right? Or should it instead be 'Chronology-Core' and 'Chronology-Tests'?
Note we also have packages named Regex-Core, Regex-Tests, SqueakSSL-Core, SqueakSSL-Tests, WebClient-Core, WebClient-Tests, which were (formerly) external packages. You want to make Chronology more like an external package, so it can be swapped out more easily.
"-Core" brings a clarity to the core unit's modular boundary, while being consistent with the number of levels in each package name that comprises that system.
Agree with Chris.
- Bert -
On Mon, Feb 22, 2016 at 02:38:43PM -0800, Bert Freudenberg wrote:
On 21.02.2016, at 10:36, Chris Muller asqueaker@gmail.com wrote:
On Sat, Feb 20, 2016 at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I need some guidance on package naming.
We have packages named 'Kernel' and 'KernelTests', 'Morphic' and 'MorphicTests', and 'Collections' and 'CollectionsTests'. Based on this, I would expect that 'Chronology' and 'ChronologyTests' would be good package names.
Is that right? Or should it instead be 'Chronology-Core' and 'Chronology-Tests'?
Note we also have packages named Regex-Core, Regex-Tests, SqueakSSL-Core, SqueakSSL-Tests, WebClient-Core, WebClient-Tests, which were (formerly) external packages. You want to make Chronology more like an external package, so it can be swapped out more easily.
"-Core" brings a clarity to the core unit's modular boundary, while being consistent with the number of levels in each package name that comprises that system.
Agree with Chris.
- Bert -
I am not seeing the update notices on the mailing list, but I just did the move of Kernel-Chronology to Chronology-Core and KernelTests-Chronology to Chronology-Tests, with update-dtl.349.mcm to add the new packages. All seems well and I can update an earlier image from the stream.
Dave
For some reason the mails have only arrived to the packages list: http://lists.squeakfoundation.org/pipermail/packages/2016-February/date.html
Levente
On Sat, 27 Feb 2016, David T. Lewis wrote:
On Mon, Feb 22, 2016 at 02:38:43PM -0800, Bert Freudenberg wrote:
On 21.02.2016, at 10:36, Chris Muller asqueaker@gmail.com wrote:
On Sat, Feb 20, 2016 at 7:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 18, 2016 at 11:54:44AM -0600, Chris Muller wrote:
I have no problem if you want move Chronology classes to their own package (but please do use the "-Core" and "-Tests" suffixes so we don't suffer the prefix selection problem). I'll be curious whether you choose to move Date and Time too..
I need some guidance on package naming.
We have packages named 'Kernel' and 'KernelTests', 'Morphic' and 'MorphicTests', and 'Collections' and 'CollectionsTests'. Based on this, I would expect that 'Chronology' and 'ChronologyTests' would be good package names.
Is that right? Or should it instead be 'Chronology-Core' and 'Chronology-Tests'?
Note we also have packages named Regex-Core, Regex-Tests, SqueakSSL-Core, SqueakSSL-Tests, WebClient-Core, WebClient-Tests, which were (formerly) external packages. You want to make Chronology more like an external package, so it can be swapped out more easily.
"-Core" brings a clarity to the core unit's modular boundary, while being consistent with the number of levels in each package name that comprises that system.
Agree with Chris.
- Bert -
I am not seeing the update notices on the mailing list, but I just did the move of Kernel-Chronology to Chronology-Core and KernelTests-Chronology to Chronology-Tests, with update-dtl.349.mcm to add the new packages. All seems well and I can update an earlier image from the stream.
Dave
On 18.02.2016, at 09:30, David T. Lewis lewis@mail.msen.com wrote:
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Why wouldn’t it work to submit a new Kernel package to inbox? Migration issue?
- Bert -
On 18.02.2016, at 09:30, David T. Lewis lewis@mail.msen.com wrote:
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Why wouldnât it work to submit a new Kernel package to inbox? Migration issue?
Yes, migration issues. The updates have to be done in steps, with old instances becomed into new at two points in the update process (in package preambles or postscripts). I can make it work at any given point, but a month later Kernel will have progressed, and I have to start over again.
Dave
On 18.02.2016, at 11:18, David T. Lewis lewis@mail.msen.com wrote:
On 18.02.2016, at 09:30, David T. Lewis lewis@mail.msen.com wrote:
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Why wouldnât it work to submit a new Kernel package to inbox? Migration issue?
Yes, migration issues. The updates have to be done in steps, with old instances becomed into new at two points in the update process (in package preambles or postscripts). I can make it work at any given point, but a month later Kernel will have progressed, and I have to start over again.
Dave
Okay. If this is a chance to get more sane date/time handling, I’m all for it :)
- Bert -
We all know there are are many use-cases, and a couple of ways to interpret things with TimeZones. Maybe we need to add a clarifying comment somewhere. Just because you think about things a particular way does not make the other ways "horrible" or not "sane". All this hyperbole does not help anyone understand what you think is wrong with Chronology. I'm certainly not going to let it be the basis for breaking legacy apps which have been working for years. Let's talk. I really didn't want to open this can of worms, but if we have to, we have to.
On Thu, Feb 18, 2016 at 1:45 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 18.02.2016, at 11:18, David T. Lewis lewis@mail.msen.com wrote:
On 18.02.2016, at 09:30, David T. Lewis lewis@mail.msen.com wrote:
I guess it has been nearly two years since I did that project. Time flies.
We discussed it on the list in thread "A UTC based implementation of DateAndTime":
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-May/178325.html
But I'm not asking you to review that project, I just wanted to suggest giving Chronology its own package so that it would be possible to do things like this. For my purposes, I can always use a SAR. But it would be a lot nicer to be able to use Monticello.
Why wouldn’t it work to submit a new Kernel package to inbox? Migration issue?
Yes, migration issues. The updates have to be done in steps, with old instances becomed into new at two points in the update process (in package preambles or postscripts). I can make it work at any given point, but a month later Kernel will have progressed, and I have to start over again.
Dave
Okay. If this is a chance to get more sane date/time handling, I’m all for it :)
- Bert -
On 17.02.2016, at 17:13, tim Rowledge tim@rowledge.org 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 -
On Wed, Feb 17, 2016 at 06:56:58PM -0800, Bert Freudenberg wrote:
On 17.02.2016, at 17:13, tim Rowledge tim@rowledge.org 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
Hi Bert,
On Feb 17, 2016, at 6:56 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 17.02.2016, at 17:13, tim Rowledge tim@rowledge.org 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 -
On 17.02.2016, at 20:10, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bert,
On Feb 17, 2016, at 6:56 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 17.02.2016, at 17:13, tim Rowledge tim@rowledge.org 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 -
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?
http://forum.world.st/file/n4878340/bug-time.png
Best, Marcel
-- View this message in context: http://forum.world.st/trunk-thinks-its-tomorrow-tp4877735p4878340.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi Marcel,
On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
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?
By my having coded time management in the Windows VM wrong? Look at sqWin32Heartbeat.c. This all needs rewriting anyway given the discussion on monotonic vs wall time. I'd like to have one copy of the code that computes the VM's notion of time, perhaps written in Smalltalk, and place that above platform-specific code that answers the monotonic and wall clocks.
But what should the VM do if it is faced with a huge jump in the time? Let's say that for testing you set the clock on your machine to 1970, then you started Smalltalk, and then you enabled syncing with the time server and the clock jumped forward to 2016. One could have the VM try to compensate but I think the best thing is to say "don't do that" and require teh user to restart their image. It's reasonable for the VM to maintain a clock that undergoes ntpd-like adjustments. It's complicated to have the VM try and distinguish small ntpd-like adjustments form huge adjustments in the clock. And keeping it simple seems like the best solution.
http://forum.world.st/file/n4878340/bug-time.png
Best, Marcel
-- View this message in context: http://forum.world.st/trunk-thinks-its-tomorrow-tp4877735p4878340.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 18.02.2016, at 12:33, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Marcel,
On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel <Marcel.Taeumel@hpi.de mailto:Marcel.Taeumel@hpi.de> wrote: 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?
By my having coded time management in the Windows VM wrong? Look at sqWin32Heartbeat.c. This all needs rewriting anyway given the discussion on monotonic vs wall time. I'd like to have one copy of the code that computes the VM's notion of time, perhaps written in Smalltalk, and place that above platform-specific code that answers the monotonic and wall clocks.
But what should the VM do if it is faced with a huge jump in the time? Let's say that for testing you set the clock on your machine to 1970, then you started Smalltalk, and then you enabled syncing with the time server and the clock jumped forward to 2016. One could have the VM try to compensate but I think the best thing is to say "don't do that" and require teh user to restart their image. It's reasonable for the VM to maintain a clock that undergoes ntpd-like adjustments. It's complicated to have the VM try and distinguish small ntpd-like adjustments form huge adjustments in the clock. And keeping it simple seems like the best solution.
Why can’t we simply decouple the low-precision wall-clock from the high-precision monotonic clock used for timing? Marcel’s use case isn’t that unusual. I put my machine to sleep with images open all the time. That should work without having to restart the image.
- Bert -
On Thu, Feb 18, 2016 at 12:49 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 18.02.2016, at 12:33, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Marcel,
On Thu, Feb 18, 2016 at 12:07 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
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?
By my having coded time management in the Windows VM wrong? Look at sqWin32Heartbeat.c. This all needs rewriting anyway given the discussion on monotonic vs wall time. I'd like to have one copy of the code that computes the VM's notion of time, perhaps written in Smalltalk, and place that above platform-specific code that answers the monotonic and wall clocks.
But what should the VM do if it is faced with a huge jump in the time? Let's say that for testing you set the clock on your machine to 1970, then you started Smalltalk, and then you enabled syncing with the time server and the clock jumped forward to 2016. One could have the VM try to compensate but I think the best thing is to say "don't do that" and require teh user to restart their image. It's reasonable for the VM to maintain a clock that undergoes ntpd-like adjustments. It's complicated to have the VM try and distinguish small ntpd-like adjustments form huge adjustments in the clock. And keeping it simple seems like the best solution.
Why can’t we simply decouple the low-precision wall-clock from the high-precision monotonic clock used for timing? Marcel’s use case isn’t that unusual. I put my machine to sleep with images open all the time. That should work without having to restart the image.
I think we must be talking about two different things. The utc coming into the VM either changes by small ammounts (via ntp) or by huge ammounts (programmer intervention). The VM can easily maintain a clock that copes with small changes to the value of utc by allowing its time, derived from the machine's monotonic time, to drift towards utc at no more than a given percentage of monotonic time. If this algorithm is used (it has the nice properties that we only need one clock for all services and that clock is acceptably accurate for measuring durations) it can't ever catch up with huge differences in teh value of utc, as would be caused by e.g. setting the system clock to 1970/1/1, starting Smalltalk and setting the time to 2016/2/18.
But that's a completely different notion to saving the image and restarting it aeons later. utc will have changed bu a huge ammount but the VM will start from the value of utc when it starts up, and has nothing to do with the time when the image was saved.
So I don't undersand hat you're getting at.
But for me I very much want to have *one clock* in tghe VM. That's an advantage of using a utc microsecond clock. All other clocks of lesser resolution can be derived from it. If you look at the situation before with a separate second clock and millisecond clock you saw absurdities like the image spin looping for up to a second (half a second on average) just to find out what the value of the millisecond clock is when the second clock ticks. Tis is absurd both because a) it wastes up to half a second on startup, a disaster in e.g. a container farm scenario and b) because it assumes that the second clock and millisecond clock are synchronised, which they aren't, so in a day or so the two will have drifted so much that timestamps will be inaccurate.
- Bert -
On 18.02.2016, at 15:16, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Feb 18, 2016 at 12:49 PM, Bert Freudenberg <bert@freudenbergs.de mailto:bert@freudenbergs.de> wrote:
Why can’t we simply decouple the low-precision wall-clock from the high-precision monotonic clock used for timing? Marcel’s use case isn’t that unusual. I put my machine to sleep with images open all the time. That should work without having to restart the image.
I think we must be talking about two different things. The utc coming into the VM either changes by small ammounts (via ntp) or by huge ammounts (programmer intervention). The VM can easily maintain a clock that copes with small changes to the value of utc by allowing its time, derived from the machine's monotonic time, to drift towards utc at no more than a given percentage of monotonic time. If this algorithm is used (it has the nice properties that we only need one clock for all services and that clock is acceptably accurate for measuring durations) it can't ever catch up with huge differences in teh value of utc, as would be caused by e.g. setting the system clock to 1970/1/1, starting Smalltalk and setting the time to 2016/2/18.
But that's a completely different notion to saving the image and restarting it aeons later. utc will have changed bu a huge ammount but the VM will start from the value of utc when it starts up, and has nothing to do with the time when the image was saved.
So I don't undersand hat you're getting at.
But for me I very much want to have *one clock* in tghe VM. That's an advantage of using a utc microsecond clock. All other clocks of lesser resolution can be derived from it. If you look at the situation before with a separate second clock and millisecond clock you saw absurdities like the image spin looping for up to a second (half a second on average) just to find out what the value of the millisecond clock is when the second clock ticks. Tis is absurd both because a) it wastes up to half a second on startup, a disaster in e.g. a container farm scenario and b) because it assumes that the second clock and millisecond clock are synchronised, which they aren't, so in a day or so the two will have drifted so much that timestamps will be inaccurate.
I thought there were two clocks. Okay.
Still, the VM should still jump the UTC clock forward if it was suspended. Backward jumps may be artificial and don’t necessarily have to be supported, but putting my machine to sleep and expecting the image to continue gracefully after wakeup seems reasonable, right?
- Bert -
On Tue, Feb 16, 2016 at 10:05:06PM -0600, Chris Muller wrote:
On Tue, Feb 16, 2016 at 1:00 PM, tim Rowledge tim@rowledge.org wrote:
On 15-02-2016, at 7:17 PM, Chris Muller asqueaker@gmail.com 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
On 17-02-2016, at 5:15 PM, David T. Lewis lewis@mail.msen.com 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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: BYEBYE: Store in Write-Only Storage
On Wed, Feb 17, 2016 at 05:35:45PM -0800, tim Rowledge wrote:
On 17-02-2016, at 5:15 PM, David T. Lewis lewis@mail.msen.com 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
On 17.02.2016, at 18:11, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com 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 -
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 -
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
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
David T. Lewis -
Eliot Miranda -
Levente Uzonyi -
marcel.taeumel -
Nicolas Cellier -
tim Rowledge