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
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
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
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:
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: long/lat - timezone map
Iain Truskett schreef dat Nick Ing-Simmons schreef: Does anyone know of a machine-readable map that can convert lat/lon to timezone? There has been some discussion about this on the Olson db mailing list. The archive of this list can be downloaded from ftp://elsie.nci.nih.gov/pub/ . You can try to contact Chuck Ellis, who made such a map in 1997. On http://www.mindspring.com/~gwil/tz.html you can find much geographical data extracted from the Olson db. That could be useful if you want to make your own map. Eugene
[ANNOUNCE] DateTime::Format::Bork 0.02
Released to CPAN. Available immediately from: http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-Bork-0.02.tar.gz Changes since 0.01 - bork() now clones passed objects thanks to Eugene van der Pijll for the bug report -J --
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 ===*/
