OT: Easter

[stanl]

Wandering through the tech db there is a trove of udf's related to datetime calculations. The 'find Easter' is particularly interesting, because I remembered when working on the udf with Deana I referenced an article that stated Easter could not be reliably calculated after year 3000 [more a physics problem than a mathematical one]. There is a post from an Australian agency that predicts it through 4099, but since no one reading this will probably be around to witness.... huge moot point.  But the math is intriguing. 

and by the way.... when converting a Julian date to day of week why add +5  before mod 7?

[EDIT] before I get scolded, I know the answer is starting the dow list with Sunday instead of Friday....   

[ChuckC]

Hmm.... I'm not finding anything in terms of formulas for converting Julian or Modified Julian to Day of  the Week that specifically calls out this issue or offers an explanation, but, at a guess, it may be related to the implementation of the Gregorian Calendar.  I might be totally wrong, but something sticks in my mind regarding the 10 days eliminated from the calendar at that point and the associated discontinuity that comes along with it.

[stanl]

If I remember the physical explanation had something to do with planetary movements and the shifting of the relationship between Easter and the Vernal Equinox.

But there is another article  http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+WinBatch/Time~-~Timer~and~Date~Functions+How~to~Get~Seconds~Ticks~Since~1970.txt

That says the script math is only good for 68 years. Assume it was posted before the Huge Math Extender, or Unix goes away as an operating system in 2038  ;D

[ChuckC]

The "Unix goes away in 2038" argument would have continued to be valid had time_t values remained 32-bit.  However, time_t values are now 64-bit, so the date in 2038 where a 32-bit integer would have rolled over is no longer an issue.

[stanl]

The "Unix goes away in 2038" argument would have continued to be valid had time_t values remained 32-bit.  However, time_t values are now 64-bit, so the date in 2038 where a 32-bit integer would have rolled over is no longer an issue.

So, if I set my PC date to 1/2/2038 and run the script in WB 32-bit it will fail and Easter will have outlived Unix?

[ChuckC]

If you continue running older 32-bit code that hasn't been updated, then, yes, you'd have a time_t value that rolled over.  Then again, pretty much any version of Windows or Unix/Linux from prior to the year 2000 w/o the "Y2K" patches would have potentially had similar types of problems  post-Y2K.

The point was, if you're running code on an operating system where due diligence has been paid in the application code and updates have been applied to the O.S., then time_t values won't be an issue in the year 2038.

[stanl]

If you continue running older 32-bit code that hasn't been updated, then, yes, you'd have a time_t value that rolled over.  Then again, pretty much any version of Windows or Unix/Linux from prior to the year 2000 w/o the "Y2K" patches would have potentially had similar types of problems  post-Y2K.

The point was, if you're running code on an operating system where due diligence has been paid in the application code and updates have been applied to the O.S., then time_t values won't be an issue in the year 2038.

Darn: there goes my novel about idiot hacker who travels back in time to 1998.

[td]

The limitation of the TimeDiffSecs function to 22000 days is to prevent integer overflow but it is not directly tied to the Unix epoch.  It's the maximum time difference between any two dates and not the difference between specific dates.