On Wed, May 16, 2012 at 01:24:20PM -0700, Randal L. Schwartz wrote:

...

...

...

...

...

"Sean" == Sean P DeNigris <sean@clipperadams.com> writes:

Sean> In New York (EST), "DateAndTime epoch" -> "1901-01-01T00:00:00-04:00" (Squeak Sean> epoch offset by local timezone). Can that be right? It must be constant, no?

But it's not even EST right now (it's EDT), so this has nothing to do with the current time offset, in case that helps. :)

"DateAndTime epoch" refers to the Smalltalk epoch, which is an undefined entity. As long as the value contains 1901-01-01T00:00:00 it is not proveably wrong, because the "definition" of the Smalltalk epoch does not specify if it is intended to refer to a point in time measured in Palo Alto, California, Greenwich England, or New York City. So no, it is not a constant. Dave

(cross posting to squeak-dev) On Wed, May 16, 2012 at 01:50:16PM -0700, Sean P. DeNigris wrote:

David T. Lewis wrote

...

So no, it is not a constant.

Let me rephrase: wouldn't it be better if it was a constant, like dos and unix?

Yes it would be better if the Smalltalk epoch was an unambiguously defined value, but unfortunately it is not. That is the reason that the clearly defined Posix epoch would be a more suitable basis for these calculations. <ot> Funny that you should mention DOS. DOS has exactly the same problem as Squeak/Pharo in this regard. It was originally designed as a simple single-user system, where the user was expected to set the clock properly on all of his/her alarm clocks, kitchen appliances, and computers. It has no knowledge of time zones or daylight savings time, and this leads to all sorts of bugs in applications running on MS-DOS that assume that the system time is correct. I was dealing with a real-life bug of this sort last week that had people spending huge amounts of time and energy trying to figure out what was causing clocks to be "reset" in a complex multi-platform application that happened to include some old DOS based computers that were sending time stamped messages. </ot>

I find the current behavior confusing e.g.

dt := '1/15/2012 0000+00:00' asDateAndTime.

DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'PDT' ]). s := dt asSeconds. "3504013200"

"Now I move to Greenwich" DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'UTC' ]). DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!"

Yes, that looks broken to me too. But DateAndTime class>>fromSeconds: is documented as "Answer a DateAndTime since the Squeak epoch: 1 January 1901" which by definition cannot be correctly implemented. One solution would be to gain agreement among all flavors of Smalltalk as to the proper definition of the Smalltalk epoch. But it seems to me that it would be vastly simpler to just use a definition that is already agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch" behind as an interesting historical artifact. Dave

Am 17.05.2012 um 05:48 schrieb "Sean P. DeNigris" <sean@clipperadams.com>:

David T. Lewis wrote

...

But it seems to me that it would be vastly simpler to just use a definition that is already agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch" behind as an interesting historical artifact.

I created an issue... Issue 5913: Remove Squeak epoch http://code.google.com/p/pharo/issues/detail?id=5913

Great Sean, I've this on my todo sheet for a long time now. I started multiple times fixing things but never finished because there is loads to do. So let's join efforts. @David That is a good proposal to base calculation on posix epoch. I blindly assumed smalltalk epoch is wrong. So I better read the specs before changing DateAndTime>>#midnight Norbert

-- View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630604.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sean, I have very little time because I need to prepare stuff for the PharoConf, so I haven't read all the mails and code that you produced on this subject. But are you sure that this is incorrect ? I am mean, combining the clock seconds with the local offset should yield a proper time, no ? The TZ of the clock is then cancelled out as far as I see it. This is code taken from https://github.com/svenvc/ztimestamp ZTimestamp class side now "Create and return a new ZTimestamp equal to the current system time" ^ self fromClockSeconds: (self clockSeconds - self clockTimezoneOffset) fromClockSeconds: seconds "Create and return a new instance from a specific number of seconds since our clock epoch, see #now" ^ self new jdn: self clockEpoch julianDayNumber + (seconds // 86400) secs: self clockEpoch secondsSinceMidnight + (seconds \\ 86400) clockEpoch "Return the epoch of the clock that we use as an instance (cached), see #now" ^ ClockEpoch ifNil: [ ClockEpoch := self year: 1901 month: 1 day: 1 ] clockSeconds "Return the total seconds count of the clock that we use as an Integer, see #now" ^ Time totalSeconds clockTimezoneOffset "Return the timezone offset of the clock that we use as an Integer seconds (cached), see #now" ^ ClockTimezoneOffset ifNil: [ ClockTimezoneOffset := DateAndTime localTimeZone offset asSeconds ] I would love to learn/discuss more, later on. It feels like you are changing dangerous things, someone else should check this out. But cleanups are of course welcome. Sven On 17 May 2012, at 21:11, Sean P. DeNigris wrote:

Fix in inbox: Name: SLICE-Issue-5913-Remove-Squeak-epoch-SeanDeNigris.1

This was a complicated change that's obviously at the core of the system. Although all 385 of KernelTests-Chronology tests pass[1], I'd really appreciate some feedback and testing...

[1] except the DateAndTime*EpochTest classes, which should be removed; see below

General * Update all comments referencing the Squeak Epoch * There is a VM primitive that returns current seconds since the Squeak epoch. For now, I have adjusted all users of this primitive for the Unix epoch, but it would be cleaner to change the primitive and remove this hack

Kernel-Chronology * Change SqueakEpoch from ChronologyConstants - rename to UnixEpoch - change value to that of UnixEpoch * Replace all uses of SqueakEpoch with UnixEpoch * change DateAndTime class>>epoch to use UTC

KernelTests-Chronology * Fix all tests to pass, except the DateAndTime*EpochTest classes, which are incredibly redundant and should be removed (Issue 5910: [Cleanup]: Gut DateAndTimeDosEpochTests) * Removed many magic numbers * cleaned and refactored

Other * Fix MailMessage and MessageList to use new epoch

-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

On 17 May 2012, at 21:11, Sean P. DeNigris wrote:

This was a complicated change that's obviously at the core of the system. Although all 385 of KernelTests-Chronology tests pass[1], I'd really appreciate some feedback and testing...

I want to have a look, but after the conference.