(sorry, didn't send to the list)
--- Begin Message ---
Rich Bowen wrote:
> I'm unclear how this is any less accurate than having a strictly seconds
> based method, and it means that we can store a wider range of dates in a
> smaller number.

Ok, I agree on using rata_die :)

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.

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?
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.

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.

- Fl�vio S. Glock

--- End Message ---

Reply via email to