DateTime::Event::Recurrence questions
Hello,
The manpage provides the example:
# second tuesday of every month
my $set = DateTime::Event::Recurrence->monthly( weeks => 2, days => 2 );
However, if I do this:
use DateTime::Event::Recurrence;
my ($start) = 1257051600;
my ($end) = 1283058000;
my ($start_dt) = DateTime->from_epoch(epoch => $start);
my ($end_dt) = DateTime->from_epoch(epoch => $end);
my ($set) = DateTime::Event::Recurrence->monthly(weeks => 2, days => 2);
my ($iterator) = $set->iterator(start => $start_dt, end => $end_dt);
while (my $dt = $iterator->next) {
printf "%s (%s)\n", scalar gmtime $dt->epoch, $dt->weekday_of_month;
}
I get the following output:
Tue Nov 10 00:00:00 2009 (2)
Tue Dec 15 00:00:00 2009 (3)
Tue Jan 12 00:00:00 2010 (2)
Tue Feb 9 00:00:00 2010 (2)
Tue Mar 9 00:00:00 2010 (2)
Tue Apr 13 00:00:00 2010 (2)
Tue May 11 00:00:00 2010 (2)
Tue Jun 15 00:00:00 2010 (3)
Tue Jul 13 00:00:00 2010 (2)
Tue Aug 10 00:00:00 2010 (2)
In December and June (months that begin on Tuesday), the event shows up on
the third weekday of the month instead of the second. Note that you get the
same behavior for any value of "days" in the set. If I use 3 for Wednesday,
I'll get the second Wednesday except for months that begin on Tuesday. Is
this a bug or am I doing something incorrectly? I'm using D::E::R v0.16.
Thanks,
Frank
Re: Potential DateTime DOS Attack
Dave Rolsky wrote: >I don't think you need auto-downloads. People download a new DT::TZ when >I release one, or they don't. No one's complained about that. It'll only rarely bite people. That doesn't make it OK. But that's an orthogonal discussion that I don't want to stray into here. >The real question for me is whether the generated binary data will be >cross-platform compatible. Are there any 32/64 bit issues? Endianness? The tzfile format is fully defined: the same binaries apply on any platform. See the DT:TZ:Tzfile code. (You'll see that it uses both 32-bit and 64-bit integer fields, all big-endian.) There's potential difficulty in using extremely far future dates on a 32-bit Perl, but that's inherent to the way DateTime uses RD. No Y2038 problem. >As long as they are cross-platform and the files can be distributed via >CPAN, I think switching to this approach would be fine. OK, I'll work on it. -zefram
Re: Potential DateTime DOS Attack
On Thu, 17 Dec 2009, Zefram wrote: Almost. In principle, the DT:TZ way of working handles far future dates slightly better. I'd actually say this doesn't matter. Look at how often time zone definitions change. Looking at America/Chicago, I see changes in 1974, 1975, 1976, 1987, and 2007. That tells me that I should not count on _anything_ being the same 30+ years from now. And the US is stable compared to some places. To get a full DT:TZ-like service from DT:TZ:Tzfile, you need a layer or two over it. I don't want to bundle the Olson files with DT:TZ:Tzfile itself: the module is for the single job of interpreting existing tzfiles. But it'd be easy to produce a module that encapsulates a full set of compiled tzfiles from Olson. Slightly harder to produce a cleverer module that automatically downloads the latest tzdata. A module layered over that could then use the tzfiles together with DT:TZ:Tzfile to provide the full Olson timezone service. And DT:TZ can then be reimplemented to use *that* as the basis for the geographic timezones. I don't think you need auto-downloads. People download a new DT::TZ when I release one, or they don't. No one's complained about that. The real question for me is whether the generated binary data will be cross-platform compatible. Are there any 32/64 bit issues? Endianness? As long as they are cross-platform and the files can be distributed via CPAN, I think switching to this approach would be fine. No one (that I recall) has asked for Posix or binary file support, so making them dependencies seems like overkill. Regarding asking for binary file support, I meant no one seemed to care about using their existing binary files. If DT::TZ depended on DT::TZ::OlsonData that would be fine. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: time_zone and DateTime::Format::Strptime
2009/12/14 Kevin McGrath > The time_zone function in DateTime::Format::Strptime is only called with > parse_datetime. I think a nice feature would be to also set the time_zone > when calling format_datetime. > Keep in mind that DateTime::Format is a framework, and consistency with other DT::Format modules is important. All the modules should extract the TZ information from the given DT object. Setting the TZ on the DT object before calling the module is the standard behavior. Whether this is good or not is a wider question. (By the way, I think that all DT::Format modules should embed the input/output TZ, as this is formatting information : you usually do not want to make DT calculations in timezones designed for humans, you usually do not want to print information for humans using timezones designed for computers). What you want breaks the current behavior by adding another convenience to a particular implementation of the interface. The time_zone option for DT::F::Strptime used for parse_datetime was already a convenience and is a design error for me. If the string does not gives the TZ, the returned object should have a floatting TZ. Olivier.
Re: Potential DateTime DOS Attack
Michael G Schwern wrote: >That looks like a great place to start. If it matches the DT::TZ >interface, and shipped a default time zone database, could DT::TZ simply >be replaced with it? Almost. In principle, the DT:TZ way of working handles far future dates slightly better. DT:TZ:Tzfile can only work from what's in the compiled tzfile. When the explicitly-listed observances run out (typically at 2038), the tzfile can only express future rules by means of a SystemV-style $TZ string. For most zones this is perfectly adequate: for example, my Debian-supplied copy of Europe/London says "GMT0BST,M3.5.0/1,M10.5.0", which accurately expresses the rule laid down by the Summer Time Order 2002. DT:TZ:Tzfile passes this string on to DT:TZ:SystemV, which does the work, and it's really DT:TZ:SystemV which is responsible for there being no silly delay for linear calculation. A handful of zones' rules cannot be adequately described in the System V style. For example, America/Santiago starts DST on whichever Sunday falls between October 9 and October 15, and has a similar rule for ending DST. This is properly described in the Olson tzdata source file, but because it can't be expressed in System V style it can't be described by a compiled tzfile. DT:TZ isn't limited by the tzfile format, because it works from the tzdata source. In the case of America/Santiago, it can therefore give correct answers for future years where the tzfile says nothing and so DT:TZ:Tzfile is forced to give up. (My copy of the compiled America/Santiago has explicitly-listed observances out to 2409, instead of the usual 2038, presumably to compensate for this limitation.) There are also some rules that DT:TZ won't handle correctly. For example, Asia/Jerusalem uses a DST-ending rule that is based on the Jewish calendar. Not only can this not be expressed in System V style, it can't be expressed in tzdata source either. Whoever wrote the tzdata source has included an explicit list of ending dates, up to 2037, and both DT:TZ and DT:TZ:Tzfile are limited to that list. (However, while DT:TZ:Tzfile recognises that its knowledge has run out, DT:TZ incorrectly extends the last indicated observance into the infinite future.) These issues affect about ten zones in the current Olson database (depending on how you count them). In principle you'd get better results by using the DT:TZ approach and just implementing it in a less dippy way. But the difference in results is not very much, and it's probably easier to get a working implementation from DT:TZ:Tzfile. It'd also avoid the need for those enormous DateTime/TimeZone/$a/$b.pm files. To get a full DT:TZ-like service from DT:TZ:Tzfile, you need a layer or two over it. I don't want to bundle the Olson files with DT:TZ:Tzfile itself: the module is for the single job of interpreting existing tzfiles. But it'd be easy to produce a module that encapsulates a full set of compiled tzfiles from Olson. Slightly harder to produce a cleverer module that automatically downloads the latest tzdata. A module layered over that could then use the tzfiles together with DT:TZ:Tzfile to provide the full Olson timezone service. And DT:TZ can then be reimplemented to use *that* as the basis for the geographic timezones. Dave Rolsky has previously objected to the idea of the default-installed DT:TZ depend on DT:TZ:Tzfile or DT:TZ:SystemV. He said in : No one (that I recall) has asked for Posix or binary file support, so making them dependencies seems like overkill. I'm happy to implement more timezone logic on top of DT:TZ:Tzfile, up to a complete drop-in DT:TZ replacement, but you'll have to argue with Dave about actually replacing the existing DT:TZ. -zefram
Re: Potential DateTime DOS Attack
Zefram wrote: J. Shirley wrote: Do not try to use named time zones (like "America/Chicago") with dates very far in the future (thousands of years). The current implementation ofDateTime::TimeZone?will use a huge amount of memory calculating all the DST changes from now until the future date. You could instead use DateTime::TimeZone::Tzfile, which does not suffer from this problem. Just requires that you have the compiled Olson files (which are freely available if you don't already have them). $zone = DateTime::TimeZone::Tzfile->new( filename => "/usr/share/zoneinfo/America/Chicago", ); $dt = DateTime->new( year => 3, month => 1, day => 1, time_zone => $zone, ); That looks like a great place to start. If it matches the DT::TZ interface, and shipped a default time zone database, could DT::TZ simply be replaced with it? DT::TZ appears to be duplicating a lot of the work that's already in a tzfile. -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
