The choise of epoch is arbitrary, Calendrical Calculations<http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/> , set it to Rata Die 0 and defines all the ones for the other calendars - Mayan, Gregorian, Julian, Persian ... - accordingly.
I did implement the Python equivalent of the Common Lisp code<goog_1788886544> from the book<http://code.google.com/p/pycalcal/source/browse/calendrica-3.0.cl>, you can browse both in my pycalcal project<http://code.google.com/p/pycalcal/>page (Python code is in the zip distribution). I have a yet unfinished implementation in Smalltalk on squeaksource called Calendrica <http://www.squeaksource.com/Calendrica>. Bye Enrico On Thu, May 17, 2012 at 2:26 AM, David T. Lewis <[email protected]> wrote: > (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 > > > -- Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick "He who refuses to do arithmetic is doomed to talk nonsense."—John McCarthy
