On Mon, 13 Jan 2003, fglock wrote: > Martijn van Beers wrote: > > Also, Date::Set does need some changes anyway, since it still relies > > on the epoch. So Date::Set is already using a dumb base class, only > > it isn't an explicit class, just a number. > > I could write a DateTime::Set, which would rely on DateTime.pm only.
Why do you think I gave you CVS write access?! Not that you can't work on other things, but I think DateTime::Set will be a very important part of the suite. > Dave Rolsky wrote: > > We'll need to store an object, but we can't do that until we have > > DateTime::TimeZone done ;) > > Do you have API ideas for DateTime::TimeZone? Yep. Besides basic accessors (like name and such) the main thing it needs to do is something like this: my $offset = $dt_tz->offset_for( $datetime ); Basically, given a _UTC_ date and time, it should return the offset for that particular datetime in the timezone. This masks all the crazy daylight savings crap behind a very simple API. The other thing it'll need to do is help the DateTime constructor, for when a user does this: my $dt = DateTime->new( (specifies date & time), timezone => $dt_tz ); Then the timezone object will have to convert the user specified datetime to UTC. The DateTime module will ask the timezone object to do this inside DateTime->new. > It could be a thin wrapper for DateTime::Set (which already handles the > recurrence and dst math) together with code that accesses the Olson > database. Yep, that makes sense. > Are we going to support leap seconds? I was thinking of implementing > it under Date::Set (using some kind of recurrences), but it fits better > into DateTime itself. I think we have to support leap seconds, but I'd like to put off that discussion for now. There's already a _lot_ of discussion threads on the list, and my hands are starting to hurt from typing so much. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
