New subject: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch

20 Jun 2012

      On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko siguctua@gmail.com wrote:
...
IMO epoch starting is completely orthogonal to timezone bug which
should simply fixed.
If you define epoch time as 1 jan 1970 (or any other date you prefer)
but still will mess up with timezones, it won't change anything isn't?
+1.  In Cog the VM has a 64-bit microsecond clock which is available both
as microseconds from 1901 UTC and in local time.   This is a great basis as
it eliminates millisecond clock rollover issues (every 49 days?), lasts for
...
50,000 years, and needs only the one primitive to answerUTC in up to
microsecond resolution, fully synchronised.  VW has been using such a basis
for about a decade.  If we could add these time primtiievs to the
Interpreter IMO we'd have a much better basis for time.
...
On 19 June 2012 21:53, Sean P. DeNigris sean@clipperadams.com wrote:
...
I wrote some tests to show the broken behavior. I'm attaching them to the
issue and
http://forum.world.st/file/n4635557/DateAndTimeTest-test_-_epoch.st to
Nabble . Comments inline below...
Eliot Miranda-2 wrote
...
...
We recently agreed that the Squeak epoch was well-defined, i.e. the
start of the 20th century in GMT.  This is clear if you read the
SMalltalk-80 V2 sources.  The reason advanced for changing to Unix was
that the Squeak epoch is not well-defined.  That argument is incorrect.
My understanding of what we found was that ST-80 referenced GMT, but
Squeak
...
was cloudy (IMO wrong) from the beginning [1]. However, the actual
constant
...
SqueakEpoch is actually a number of julian days, so that *could* stay
unchanged if we decide that way.
[1]
http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tp4630581p...
...
Eliot Miranda-2 wrote
...
...
Further, the Squeak epoch is embedded in the VMs, in their answering
both
...
...
...
seconds and microseconds from the epoch.  So there's work involved in
getting rid of it.
This test indicates to me that the VM is using the same (wrong) logic as
the
...
image:
   testSqueakEpochClock
   | secondsFromClock secondsSinceEpochUTC |
   self useTimeZone: 'EDT' during: [
           secondsFromClock := Time primSecondsClock.
           secondsSinceEpochUTC := (DateAndTime now -

'1901-01-01T00:00:00+00:00'
...
asDateAndTime) asSeconds.
           "Fails because the clock returns the number of seconds

since
...
1901-01-01T00:00:00+(localOffset)"
               self deny: secondsFromClock = (secondsSinceEpochUTC +
DateAndTime
...
localOffset asSeconds).
               self assert: secondsFromClock equals:
secondsSinceEpochUTC ].
...
Stéphane Ducasse wrote
...
Now Sean what was your problem? Because may be we can also improve
Squeak-epoch.
Any time a DateAndTime is converted to seconds, the result is "the
number of
...
seconds since 1901-01-01T00:00:00+(localOffset)", which is indeterminate.
For example (see #testSqueakEpochAcrossTimeZones):

aDateAndTime asSeconds.
quit the image
move to a different time zone (or set localTimeZone: to a different

tz)
...

open the image again
restore the DateAndTime e.g. #fromSeconds:

It is a different DateAndTime!!
I'm clear (but please review the tests) that whatever epoch we choose:

the implementation *around* it must be fixed
the VM should be changed
any existing integers representing DateAndTime's will be invalid

I think the only reason we've gotten this far without anyone noticing is
that they are converted to/from integers in the same incorrect way in
both
...
directions, so unless you transport live instances into a different time
zone, you would never notice.
The only question that I see we've come down to is:

keep the Squeak epoch, because it is elegant (turn of the century...)

or

use the Unix epoch, because it is well-known and documented

This is honestly much less important than the givens above, so this is
what
...
I'll do... I'm going to create a new issue and to fix the image-side
issues
...
I mentioned, and we can have fun debating this last question, which
seems to
...
come down to style, ad infinitum ;-)
Sean
--
View this message in context:
http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-...
...
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
--
Best regards,
Igor Stasenko.
-- 
best,
Eliot

Re: [Pharo-project] who can have a look at Issue 5913: Remove Squeak epoch