At 21:09 -0700 4/23/10, Darren Duncan wrote: >I think that the most thorough solution is to just take it for granted that >there are multiple reference timelines/calendars and that in general it is >impossible to reconcile them with each other.
At 15:46 -0700 4/24/10, Darren Duncan wrote: >All details specific to any calendar, including Gregorian, including concepts >like seconds or hours or days, should be left out of the core and be provided >by separate modules. Said modules can be self-contained, just say using >Perl's ordinary numeric and string types for internal representation, and >Perl's single core now() routine they can use to determine the current >datetime, and the module can introspect its result or calendar() and figure >out how to map that to the internal representation or API it wants to use, as >well as figure out the proper way to invoke sleep(). At 19:25 -0400 4/24/10, Mark J. Reed wrote: >Absolutely ridiculous. The Gregorian calendar is in universal use for >civil purposes and definitely belongs in the core. Please accept a plug for Darren. With all of the political and religious problems associated with calendars I would really like to see perl step aside and do ALL of that in modules or perhaps with use of libraries and methods provided by the operating system in which perl is a current process. Atomic seconds per mean solar day is not a constant and might be changed by political action. Mean solar days per year is determined by your God who tells the earth how fast to spin. Ditto for atomic seconds per year. Days in a month is so screwed up that folks argue about age of children when qualifying for benefits. Please just give up and get perl 6 running without trying to lead the world. Make it easy to set up optional schemes as particular users require. Use the epoch as defined in the operating system or, if undefined, use the start of 1970. You could take the instant of perihelion in what Gregorian people think was 1970 years after some important instant. Well, perhaps is was 1969 years if 0000 was Roman numeral I. Do everything in a way totally independent of earthly coordinates of the computer in use. But do assume it's motionless with respect to Earth in a 1 g field perhaps at Greenwich UK or Fort Collins CO. Agree on a format for storing fractional atomic seconds. There are proposals for two word integers with one of them being micro or nano seconds and the other seconds. I prefer IEEE floating point with atomic seconds as the unit of measure. That's a bit like MS Excel where days are used for the unit. The Excel scheme is not as clean because it assumes 86400 seconds in a day and it's a day off between what it thinks was Feb 29, 1900 and its epoch at the start of 1900. In any case users need a time value that can be negative or large positive. It's OK to lose precision for time points a long way from the current epoch. Floating point handles that nicely. We really don't care what day of the week the big bang started on but we really would like to use whatever time system is "standard" to perl. We'd also like to record time differences between collisions in the new CERN accelerator or the arrival times of entangled photons. Easter is the first Sunday after the first full moon after the vernal equinox - - - except. Some pope ordered a calculation of the date for some 3000 years in advance. He blessed the result. So the rule holds except for the mistakes made 1000 years ago. I learned that in 1961 which is the only year of error in my lifetime. Please don't ask perl 6 to pontificate on things like that. -- --> If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. <--
