On Fri, 1 Aug 2003, Joshua Hoblitt wrote:
[1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
I committed this change to CVS but I think it may have uncovered some
sort of weird bug in DT::TZ. Could you run the tests from the CVS
version and let me know if they hang?
It's not
On Fri, 1 Aug 2003, Joshua Hoblitt wrote:
[1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
I committed this change to CVS but I think it may have uncovered some
sort of weird bug in DT::TZ. Could you run the tests from the CVS
version and let me know if they hang?
I take it
Dave Rolsky wrote:
It's just that it has to generate _all_
the time zone changes up to the year !!
That's going to take a while. I'd recommend using a year a little closer
to our own. DT::TZ ships with the changes pre-generated 30 years out, so
dates in that range are quick. Dates
Dave Rolsky [EMAIL PROTECTED] schrieb/wrote:
That's going to take a while. I'd recommend using a year a little
closer to our own. DT::TZ ships with the changes pre-generated 30
years out, so dates in that range are quick.
Why does DT::TZ work that way? It should be possible to determine
Dave Rolsky wrote:
On Fri, 1 Aug 2003, Flavio S. Glock wrote:
Is this really necessary? It could generate sparse time-zone tables.
Can you explain what you mean? Looking at the code in question is not
enlightening me.
This is some pseudo-code:
$year = $dt-year;
generate_tz( \%tz,
On Fri, 1 Aug 2003, Claus Färber wrote:
Dave Rolsky [EMAIL PROTECTED] schrieb/wrote:
That's going to take a while. I'd recommend using a year a little
closer to our own. DT::TZ ships with the changes pre-generated 30
years out, so dates in that range are quick.
Why does DT::TZ work
Perhaps it is useful to specify a rule that DT::Format formatting
routines should never change the object they are passed. Before changing
anything, clone the object first. Is this something to add to the
development standards?
Thats a _very_ good idea.
[1] Why UTC? Wouldn't
