<br><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 1:50 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO epoch starting is completely orthogonal to timezone bug which<br>
should simply fixed.<br>
If you define epoch time as 1 jan 1970 (or any other date you prefer)<br>
but still will mess up with timezones, it won't change anything isn't?<br></blockquote><div><br></div><div>+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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
On 19 June 2012 21:53, Sean P. DeNigris <<a href="mailto:sean@clipperadams.com">sean@clipperadams.com</a>> wrote:<br>
> I wrote some tests to show the broken behavior. I'm attaching them to the<br>
> issue and<br>
> <a href="http://forum.world.st/file/n4635557/DateAndTimeTest-test_-_epoch.st" target="_blank">http://forum.world.st/file/n4635557/DateAndTimeTest-test_-_epoch.st</a> to<br>
> Nabble . Comments inline below...<br>
><br>
><br>
> Eliot Miranda-2 wrote<br>
>><br>
>>> We recently agreed that the Squeak epoch was well-defined, i.e. the<br>
>>> start of the 20th century in GMT. This is clear if you read the<br>
>>> SMalltalk-80 V2 sources. The reason advanced for changing to Unix was<br>
>>> that the Squeak epoch is not well-defined. That argument is incorrect.<br>
>><br>
><br>
> My understanding of what we found was that ST-80 referenced GMT, but Squeak<br>
> was cloudy (IMO wrong) from the beginning [1]. However, the actual constant<br>
> SqueakEpoch is actually a number of julian days, so that *could* stay<br>
> unchanged if we decide that way.<br>
><br>
> [1]<br>
> <a href="http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tp4630581p4630834.html" target="_blank">http://forum.world.st/Re-Pharo-project-Epoch-returns-local-offset-tp4630581p4630834.html</a><br>
><br>
><br>
> Eliot Miranda-2 wrote<br>
>><br>
>>> Further, the Squeak epoch is embedded in the VMs, in their answering both<br>
>>> seconds and microseconds from the epoch. So there's work involved in<br>
>>> getting rid of it.<br>
>><br>
> This test indicates to me that the VM is using the same (wrong) logic as the<br>
> image:<br>
> testSqueakEpochClock<br>
><br>
> | secondsFromClock secondsSinceEpochUTC |<br>
> self useTimeZone: 'EDT' during: [<br>
> secondsFromClock := Time primSecondsClock.<br>
> secondsSinceEpochUTC := (DateAndTime now - '1901-01-01T00:00:00+00:00'<br>
> asDateAndTime) asSeconds.<br>
><br>
> "Fails because the clock returns the number of seconds since<br>
> 1901-01-01T00:00:00+(localOffset)"<br>
> self deny: secondsFromClock = (secondsSinceEpochUTC + DateAndTime<br>
> localOffset asSeconds).<br>
> self assert: secondsFromClock equals: secondsSinceEpochUTC ].<br>
><br>
><br>
> Stéphane Ducasse wrote<br>
>><br>
>> Now Sean what was your problem? Because may be we can also improve<br>
>> Squeak-epoch.<br>
>><br>
> Any time a DateAndTime is converted to seconds, the result is "the number of<br>
> seconds since 1901-01-01T00:00:00+(localOffset)", which is indeterminate.<br>
> For example (see #testSqueakEpochAcrossTimeZones):<br>
> 1. aDateAndTime asSeconds.<br>
> 2. quit the image<br>
> 3. move to a different time zone (or set localTimeZone: to a different tz)<br>
> 4. open the image again<br>
> 5. restore the DateAndTime e.g. #fromSeconds:<br>
> It is a different DateAndTime!!<br>
><br>
> I'm clear (but please review the tests) that whatever epoch we choose:<br>
> - the implementation *around* it must be fixed<br>
> - the VM should be changed<br>
> - any existing integers representing DateAndTime's will be invalid<br>
><br>
> I think the only reason we've gotten this far without anyone noticing is<br>
> that they are converted to/from integers in the same incorrect way in both<br>
> directions, so unless you transport live instances into a different time<br>
> zone, you would never notice.<br>
><br>
> The only question that I see we've come down to is:<br>
> - keep the Squeak epoch, because it is elegant (turn of the century...)<br>
> or<br>
> - use the Unix epoch, because it is well-known and documented<br>
> This is honestly much less important than the givens above, so this is what<br>
> I'll do... I'm going to create a new issue and to fix the image-side issues<br>
> I mentioned, and we can have fun debating this last question, which seems to<br>
> come down to style, ad infinitum ;-)<br>
><br>
> Sean<br>
><br>
> --<br>
> View this message in context: <a href="http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4635557.html" target="_blank">http://forum.world.st/who-can-have-a-look-at-Issue-5913-Remove-Squeak-epoch-tp4634003p4635557.html</a><br>
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.<br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Best regards,<br>
Igor Stasenko.<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>