On Mon, 13 Jan 2003, Rich Bowen wrote: > So the internals would become ... what exactly? Right now, there are two > integers stored - the "julian day", which is not actually the julian > day, and the seconds, which is seconds since midnight (although I tend
Sorry, I wasn't clear. I meant that since we are _already_ storing rata die days plus seconds past midnight, we should change the _names_ of the various methods and hash elements in the code, so that they don't misleadingly say julian. That's all. > to get confused all the time about what timezone this is actually stored > in - your local one, or GMT). We also store the offset (ie, > hours offset from GMT) which is a 5-character string that looks like > "-0100" or "+0430". Timezones are hard. We'll need to store an object, but we can't do that until we have DateTime::TimeZone done ;) > Changing the "julian day" bit to rata die is goodness, and this is a > good time to do it. Moreover, if the base object has rata die stored, > rather than julian, I could finally finish all the DateTime::Calendar > classes that I have half finished. Yep. I'm thinking we'll offer a method: my ($days, $secs, $nanosecs) = $datetime->rata_die and declare that the standard method for inter-operability, so _all_ calendars must implement it. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
