The choise of epoch is arbitrary, <a href="http://emr.cs.iit.edu/home/reingold/calendar-book/third-edition/">Calendrical Calculations</a>,<div>set it to Rata Die 0 and defines all the ones for the other calendars</div><div>
- Mayan, Gregorian, Julian, Persian ... - accordingly.</div><div><br></div><div>I did implement the Python equivalent of the <a href="goog_1788886544">Common Lisp code</a></div><div><a href="http://code.google.com/p/pycalcal/source/browse/calendrica-3.0.cl">from the book</a>, you can browse both in my <a href="http://code.google.com/p/pycalcal/">pycalcal project</a> page</div>
<div>(Python code is in the zip distribution).</div><div><br></div><div>I have a yet unfinished implementation in Smalltalk on squeaksource</div><div>called <a href="http://www.squeaksource.com/Calendrica">Calendrica</a>.</div>
<div><br></div><div>Bye</div><div>Enrico</div><div><br><div class="gmail_quote">On Thu, May 17, 2012 at 2:26 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(cross posting to squeak-dev)<br>
<br>
On Wed, May 16, 2012 at 01:50:16PM -0700, Sean P. DeNigris wrote:<br>
><br>
> David T. Lewis wrote<br>
> ><br>
> > So no, it is not a constant.<br>
> ><br>
><br>
> Let me rephrase: wouldn't it be better if it was a constant, like dos and<br>
> unix?<br>
<br>
Yes it would be better if the Smalltalk epoch was an unambiguously defined<br>
value, but unfortunately it is not. That is the reason that the clearly<br>
defined Posix epoch would be a more suitable basis for these calculations.<br>
<br>
<ot><br>
Funny that you should mention DOS. DOS has exactly the same problem<br>
as Squeak/Pharo in this regard. It was originally designed as a simple<br>
single-user system, where the user was expected to set the clock properly<br>
on all of his/her alarm clocks, kitchen appliances, and computers. It<br>
has no knowledge of time zones or daylight savings time, and this leads<br>
to all sorts of bugs in applications running on MS-DOS that assume that<br>
the system time is correct. I was dealing with a real-life bug of this<br>
sort last week that had people spending huge amounts of time and energy<br>
trying to figure out what was causing clocks to be "reset" in a complex<br>
multi-platform application that happened to include some old DOS based<br>
computers that were sending time stamped messages.<br>
</ot><br>
<br>
> I find the current behavior confusing e.g.<br>
><br>
> dt := '1/15/2012 0000+00:00' asDateAndTime.<br>
><br>
> DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation<br>
> = 'PDT' ]).<br>
> s := dt asSeconds. "3504013200"<br>
><br>
> "Now I move to Greenwich"<br>
> DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation<br>
> = 'UTC' ]).<br>
> DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!"<br>
><br>
<br>
Yes, that looks broken to me too. But DateAndTime class>>fromSeconds: is<br>
documented as "Answer a DateAndTime since the Squeak epoch: 1 January 1901"<br>
which by definition cannot be correctly implemented.<br>
<br>
One solution would be to gain agreement among all flavors of Smalltalk<br>
as to the proper definition of the Smalltalk epoch. But it seems to me<br>
that it would be vastly simpler to just use a definition that is already<br>
agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch"<br>
behind as an interesting historical artifact.<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Enrico Spinielli<br>"Do Androids dream of electric sheep?"— Philip K. Dick<br>"Hear and forget; see and remember;do and understand."—Mitchel Resnick<br>
"He who refuses to do arithmetic is doomed to talk nonsense."—John McCarthy<br>
</div>