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, I'd really
appreciate some feedback and testing...
 except the DateAndTime*EpochTest classes, which should be removed; see
* 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
* 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
* Fix all tests to pass, except the DateAndTime*EpochTest classes, which
are incredibly redundant and should be removed (Issue 5910: [Cleanup]: Gut
* Removed many magic numbers
* cleaned and refactored
* Fix MailMessage and MessageList to use new epoch
I had a quick look at the changes when merging in an up to date 2.0
The slice isn't clean (any more): it removes Character and many others
thing, I don't understand.
The relevant changes seem OK.
One thing that worries me is that the Epoch instance is not cached, neither
is differenceBetweenSqueakAndUnixEpochs. The result is that doing something
which certain systems could do very frequently, creates tons of garbage.
This should be fast: get the system clock and create one object, not
recompute differenceBetweenSqueakAndUnixEpochs by parsing strings, every
I also see a change in Delay, which is probably bogus due to the late
merge, I don't know.
> Sean could you have a look and may be produce a new version?
I'd be happy to, but first... 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
- why reinvent the wheel? Everybody already knows what the unix epoch is
(e.g. you can point them to Wikipedia)
The main thing is to make sure that whatever we use is based on UTC and not
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
This issue is pending a discussion on the mailing list . I probably will
want to do the fix again either way. And I've created a new issue  for
the most pressing problem, which is the incorrect behavior.
I'm attaching a file out of tests (DateAndTimeTest, protocol 'test -
epoch') showing the problems with the way the epoch is currently handled.