(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 ---