Re: Bug in DT::F::Bork
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 that way? It should be possible to determine > whether a date is DST without generating data for all the years > inbetween. Because this was relatively easy to implement. It uses more or less the same code as is used to generate the initial data set. > (The problem is, of course, that it will need year, month, and time > information for that and so probably must create a DT object w/ UTC > timezone ... or use DateTime::_rd2ymd) Well, it does that anyway. Basically it comes down to this being quite a bit easier than a sparse implementation. A sparse implementation would be more complex, especially since I'm afraid that someday we'll see a time zone with > 2 changes per year (you never know). If someone else wants to work on a patch, I'd be happy to accept it ;) However, what I'd really like to do is rewrite all of this in XS, at which point it might not make much difference. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
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, $year ) unless exists $tz{$year};
do_something( $tz{$year}, $dt );
Note that I didn't read the DT::TZ sources - I may be wrong.
- Flavio S. Glock
Re: Bug in DT::F::Bork
On Fri, 1 Aug 2003, Flavio S. Glock 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. Dates within a couple hundred years out > > aren't too bad either, but thousands of years ahead will be slow. > > Is this really necessary? It could generate sparse time-zone tables. > > (Date::Set::Timezone does this - maybe some ideas can be reused) Can you explain what you mean? Looking at the code in question is not enlightening me. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
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 whether a date is DST without generating data for all the years inbetween. (The problem is, of course, that it will need year, month, and time information for that and so probably must create a DT object w/ UTC timezone ... or use DateTime::_rd2ymd) Claus -- http://www.faerber.muc.de
Re: Bug in DT::F::Bork
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 within a couple hundred years out > aren't too bad either, but thousands of years ahead will be slow. Is this really necessary? It could generate sparse time-zone tables. (Date::Set::Timezone does this - maybe some ideas can be reused) - Flavio S. Glock
Re: Bug in DT::F::Bork
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 back, there's no bug. 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 within a couple hundred years out aren't too bad either, but thousands of years ahead will be slow. I should probably document this somewhere more obvious. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
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 hanging, it's just _really_ slow. I'll look into it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
> [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? -J --
Re: Bug in DT::F::Bork
> 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 Europe/Stockholm be more appropriate? Bork. -J --
