who can have a look at Issue 5913: Remove Squeak epoch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

who can have a look at Issue 5913: Remove Squeak epoch

Stéphane Ducasse
I will review it but I would like to know if somebody else can have a look at it
        http://code.google.com/p/pharo/issues/detail?id=5913

Stef
Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Sean P. DeNigris
Administrator
Do we all agree that standardizing on the Unix Epoch is the way to go? The argument on the squeak list seemed to be:
- the squeak epoch has a certain beauty to it, being the turn of the century
vs
- why reinvent the wheel? Everybody already knows what the unix epoch is (e.g. you can point them to Wikipedia)

The full discussion is here: http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814

The main thing is to make sure that whatever we use is based on UTC and not local time.

So - two options
- PharoOffset := 1 January, 1901 UTC
- Unix offset

Also, whatever we change it to (and IMHO it really needs to be changed), I think existing live objects from previous Pharos (e.g. that are materialized with fuel) may be invalid (like the recent zip/mcz consequences)
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Eliot Miranda-2


On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris <[hidden email]> wrote:
Do we all agree that standardizing on the Unix Epoch is the way to go?

No :)
 
The
argument on the squeak list seemed to be:
- the squeak epoch has a certain beauty to it, being the turn of the century
vs
- why reinvent the wheel? Everybody already knows what the unix epoch is
(e.g. you can point them to Wikipedia)

The full discussion is here:
http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814

The main thing is to make sure that whatever we use is based on UTC and not
local time.

So - two options
- PharoOffset := 1 January, 1901 UTC
- Unix offset

Also, whatever we change it to (and IMHO it really needs to be changed), I
think existing live objects from previous Pharos (e.g. that are materialized
with fuel) may be invalid (like the recent zip/mcz consequences)

--
View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4634403.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Stéphane Ducasse

On Jun 12, 2012, at 5:51 AM, Eliot Miranda wrote:

>
>
> On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris <[hidden email]> wrote:
> Do we all agree that standardizing on the Unix Epoch is the way to go?
>
> No :)

Why?

>  
> The
> argument on the squeak list seemed to be:
> - the squeak epoch has a certain beauty to it, being the turn of the century
> vs
> - why reinvent the wheel? Everybody already knows what the unix epoch is
> (e.g. you can point them to Wikipedia)
>
> The full discussion is here:
> http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814
>
> The main thing is to make sure that whatever we use is based on UTC and not
> local time.
>
> So - two options
> - PharoOffset := 1 January, 1901 UTC
> - Unix offset
>
> Also, whatever we change it to (and IMHO it really needs to be changed), I
> think existing live objects from previous Pharos (e.g. that are materialized
> with fuel) may be invalid (like the recent zip/mcz consequences)
>
> --
> View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4634403.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>
>
>
> --
> best,
> Eliot
>


Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Eliot Miranda-2


On Mon, Jun 11, 2012 at 10:42 PM, Stéphane Ducasse <[hidden email]> wrote:

On Jun 12, 2012, at 5:51 AM, Eliot Miranda wrote:

>
>
> On Mon, Jun 11, 2012 at 7:15 PM, Sean P. DeNigris <[hidden email]> wrote:
> Do we all agree that standardizing on the Unix Epoch is the way to go?
>
> No :)

Why?

If it ain't broke don't fix it.  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.

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.  
 
As far as I can see changing it is pointless wasted effort.


>
> The
> argument on the squeak list seemed to be:
> - the squeak epoch has a certain beauty to it, being the turn of the century
> vs
> - why reinvent the wheel? Everybody already knows what the unix epoch is
> (e.g. you can point them to Wikipedia)
>
> The full discussion is here:
> http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814
>
> The main thing is to make sure that whatever we use is based on UTC and not
> local time.
>
> So - two options
> - PharoOffset := 1 January, 1901 UTC
> - Unix offset
>
> Also, whatever we change it to (and IMHO it really needs to be changed), I
> think existing live objects from previous Pharos (e.g. that are materialized
> with fuel) may be invalid (like the recent zip/mcz consequences)
>
> --
> View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4634403.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>
>
>
> --
> best,
> Eliot
>





--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Stéphane Ducasse

> Why?
>
> If it ain't broke don't fix it.

well with that argument we would still have image segment, projects, fileDirectory (soon killed), HttpSocket and other not broken but ugly citizen in the system.

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

OK this is a good argument to me.
>  
> As far as I can see changing it is pointless wasted effort.

I would not say it like that. Because there is a lot of work we do that look pointless but are clearly not. Soon a lot of them will
really pay off (ring, nautilus, spec, athens, zinc).

Now Sean what was your problem? Because may be we can also improve Squeak-epoch.

Stef

>
>
> >
> > The
> > argument on the squeak list seemed to be:
> > - the squeak epoch has a certain beauty to it, being the turn of the century
> > vs
> > - why reinvent the wheel? Everybody already knows what the unix epoch is
> > (e.g. you can point them to Wikipedia)
> >
> > The full discussion is here:
> > http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-td4630581.html#a4630814
> >
> > The main thing is to make sure that whatever we use is based on UTC and not
> > local time.
> >
> > So - two options
> > - PharoOffset := 1 January, 1901 UTC
> > - Unix offset
> >
> > Also, whatever we change it to (and IMHO it really needs to be changed), I
> > think existing live objects from previous Pharos (e.g. that are materialized
> > with fuel) may be invalid (like the recent zip/mcz consequences)
> >
> > --
> > View this message in context: http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4634403.html
> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> >
> >
> >
> >
> > --
> > best,
> > Eliot
> >
>
>
>
>
>
> --
> best,
> Eliot
>


Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Sean P. DeNigris
Administrator
I wrote some tests to show the broken behavior. I'm attaching them to the issue and 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-tp4630581p4630834.html

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):
1. aDateAndTime asSeconds.
2. quit the image
3. move to a different time zone (or set localTimeZone: to a different tz)
4. open the image again
5. 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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Igor Stasenko
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?


On 19 June 2012 21:53, Sean P. DeNigris <[hidden email]> 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-tp4630581p4630834.html
>
>
> 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):
> 1. aDateAndTime asSeconds.
> 2. quit the image
> 3. move to a different time zone (or set localTimeZone: to a different tz)
> 4. open the image again
> 5. 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-tp4634003p4635557.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: who can have a look at Issue 5913: Remove Squeak epoch

Eliot Miranda-2


On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko <[hidden email]> 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 <[hidden email]> 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-tp4630581p4630834.html
>
>
> 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):
> 1. aDateAndTime asSeconds.
> 2. quit the image
> 3. move to a different time zone (or set localTimeZone: to a different tz)
> 4. open the image again
> 5. 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-tp4634003p4635557.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



--
Best regards,
Igor Stasenko.




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
On Tue, Jun 19, 2012 at 03:32:47PM -0700, Eliot Miranda wrote:
>  
> On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko <[hidden email]> 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?
> >

Absolutely right.

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

Eliot,

Could I ask you to please take a second look at primitiveUtcWithOffset?
This has been in trunk VMMaker with platform support for Windows/Unix/Mac
for a couple of years now, and the background and discussion is on Mantis
at http://bugs.squeak.org/view.php?id=7458.

The underlying platform call is ioUtcWithOffset(&clock, &offset) which
could presumably be adapted to support your Cog primitives. Would this make
sense?

Dave