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....
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-... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- best, Eliot
-- best, Eliot