Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sat, 11 Jan 2003 16:44:37 -0500 (EST), [EMAIL PROTECTED] wrote: On Sat, 11 Jan 2003, Dave Rolsky wrote: You know, on reflection, I don't think the internals matter _at all_ (well, they need to work, but you already took care of that ;) What matters is that we can return a _standard_ value for the use of other calendar implementers. Yes, that is the conclusion that we came to. Indeed, we changed the internals at least twice, with no change to the API. Date::ICal uses what Calendrical Calculations uses (that they call Rata Die, fixed date). They are days on or after Jan 1 of year 1 (Gregorian). This different from MJD. I'd like to see Date::ICal switch to using rd to describe them instead of jd in some places and julian in others. The greg2jd and jd2greg functions should work for any R.D. between minint and maxint inclusive. This gives a range of 11.75+ million years with 32 bit ints and 50 quadrillion years with 64 bit ints. The only other function that really needs to access the internal format is day_of_week. greg2jd is also supposed to return correctly normalized results for any integer values given (e.g. with year -1200, month 1, and day 21, you should get the R.D. 2 billion days after the start of year -1200.). The subs greg2jd and jd2greg and the tests in 09greg.t are are in the public domain. They are based on ideas from the first edition of Calendrical Calculations (especially the Cycles of Years section) but use no actual algorithms from it (which may be under copyright and/or patent protection--though I think Rich Bowen does have an arrangement with the authors for some of his work.) They do resemble the alternate Gregorian functions in the second edition.
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote: Date::ICal uses what Calendrical Calculations uses (that they call Rata Die, fixed date). They are days on or after Jan 1 of year 1 (Gregorian). This different from MJD. I'd like to see Date::ICal switch to using rd to describe them instead of jd in some places and julian in others. Aha. I just ordered this book, and it should be here next week. So this particular calculation is documented somewhere outside Date::ICal? That is a good thing. As to switching the internals, that sounds like a good idea, since it's misleading as is. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sat, 11 Jan 2003, Dave Rolsky wrote: No, this has nothing to do with Mr. Dominus. Rich, can you explain the pseudo-mjd system that Date::ICal uses for its internals? And why didn't you you use real MJD? It is MJD + an offset (or - an offset, as the case may be). It makes the calculations just a little faster when you are starting from some known date that is closer to dates that we are likely to be using. It makes the numbers that we're dealing with smaller. I think that there were other reasons. I'd have to paw through the archives. However, the actual number being stored can be changed to real MJD, and the whole thing would remain internally consistent. I think. And might end up being a little easier, since Calendrical Calculations uses that number as well. But I could be remembering wrong. Any of the other Reefknot folks remember? Inquiring minds want to know. I think this is particularly important since I was hoping to use this format as the basis for interoperability, but I'd more comfortable with a real standard for that (I suppose ICal fits the bill there, but it requires everyone to parse things out over and over). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Pilgrim, how you journey on the road you chose To find out where the winds die and where the stories go --Pilgrim (Enya - A Day Without Rain)
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sat, 11 Jan 2003, Dave Rolsky wrote: You know, on reflection, I don't think the internals matter _at all_ (well, they need to work, but you already took care of that ;) What matters is that we can return a _standard_ value for the use of other calendar implementers. Yes, that is the conclusion that we came to. Indeed, we changed the internals at least twice, with no change to the API. -- Rich Bowen - [EMAIL PROTECTED] http://kenya.rcbowen.com/
