Re: DateTime::Duration, length of a month?
Joshua Hoblitt schreef: When converting a DateTime::Duration month to days - how many days should it be considering equivalent too? 30? 30.4? 31? If you want to do this, you have to take into account that a duration of $x years is translated to 12*$x years internally. If your calendar has no months, it should calculate the number of days to add as $delta_days + int( $delta_months * $DAYS_IN_YEAR/12 ); Problem with the Mayan calendar: it has no years either... But one of the smaller counts (haab) is 365 days long, I believe. So that is probably the Mayan idea of a year. (As usual) I disagree with Dave: some people would find it useful to use durations in any calendar, so why not implement them. As long as they use days and years only, there is no problem. And if they try to add a number of months to a Mayan date, they shouldn't complain about the result. Eugene
Re: DateTime::Duration, length of a month?
At 12:05 PM +0200 5/4/03, Eugene van der Pijll wrote: Problem with the Mayan calendar: it has no years either... But one of the smaller counts (haab) is 365 days long, I believe. So that is probably the Mayan idea of a year. (As usual) I disagree with Dave: some people would find it useful to use durations in any calendar, so why not implement them. As long as they use days and years only, there is no problem. And if they try to add a number of months to a Mayan date, they shouldn't complain about the result. Sure there should be Durations, but not DateTime::Durations. DateTime durations are based on the Gregorian Calendar. If you want to include durations they should be Mayan durations. $mayan_duration = DateTime::Calendar::Mayan::Duration-new( baktuns=1, haabs = 8, ) AFAICT there'd be no way to use -from_object unless you convert the ::Mayan back into Gregorian, add/subtract the object, then convert it back into Mayan. I imagine that on the whole Mayan will generally be used to convert from a DateTime into Mayan (and vice-versa). I don't think the call for inter-calendar durations will be too strong. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: Time::Local (was: Bundle::DateTime)
On Fri, 4 Apr 2003, Iain 'Spoon' Truskett wrote: Are there details of how MakeMaker and CPAN.pm treat 0 and undef in prereqs? It's treated as any version. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::Event::Basic
On Thu, 3 Apr 2003, Flavio S. Glock wrote:
Flavio S. Glock wrote:
DateTime::Event::Basic - A base class for building Event classes.
Ok, I think I'll explain this a bit more:
For example, DateTime::Event::Sunset would be simplified to:
@ISA = qw( DateTime::Event::Basic );
sub initialize {
[snipped param checking]
$self-{event_name} = $parm{event};
$self-{logitude} = $parm{longitude};
$self-{latitude} = $parm{latitude};
$self-{next} = \_next_sunrise if $self-{event_name} eq 'sunrise';
$self-{next} = \_next_sunset if $self-{event_name} eq 'sunset';
$self-SUPER::initialize;
}
I think the problem is that this (AFAICT) forces all events to be dealt
with as sets internally, which may not be what many module authors want to
do.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Bug in epoch handling [patch]
On Tue, 1 Apr 2003, Iain 'Spoon' Truskett wrote: * Iain 'Spoon' Truskett ([EMAIL PROTECTED]) [01 Apr 2003 13:18]: Adding and subtracting small durations doesn't appear to affect the epoch. I tried adding a line to recalculate it, but that just seemed to screw things up elsewhere. Ok. After having a break for lunch and doing some other stuff: This probably isn't perfect; I've not really examined how the internals of DT.pm operate. On the other hand, it does still pass all tests =) I fixed this a slightly differnet way, but the tests were helpful. Thanks, -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Announce: DateTime-Format-Builder 0.25
On Mon, 31 Mar 2003, Joshua Hoblitt wrote: I started implementing all of ISO8601:2000 last night with Builder.pm. After looking at the pod for awhile I started thinking that this could be simplified [and optimized] a little if you don't mind dirtying the namespace. Some POEish like this: my ($date, $p) = @_[ INPUT, PARSED ]; Ugh, this is _so_ ugly, and it's a really silly micro-optimization. In most normal code, you spend most of your time doing stuff, not passing arguments, so optimizing argument passing is generally not going to be much of a win. And it's certainly not worth it when it forces such weird non-standard internals. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::Format::ICal 0.03
0.03 2003-04-05 - Handle offset-only time zones without producing garbage output. Bug report from Iain Truskett. - Switch to Module::Build. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: invitation to DateTime module authors
On Fri, 4 Apr 2003, Dave Rolsky wrote: If you're written a DateTime module and you'd like to have it be part of the perl-date-time CVS project, this is in invitation to join. The advantages are: - shared CVS, which means you can edit the website (particularly them module list), dev docs, etc. - commit emails (if you care) - I or others might fix bugs in your code for you The disadvantages are: - You'll most likely have me poking into your code at one point or another. If the idea of me doing this bothers you, then you this is a disadvantage ;) Email me if interested. Since this whole thing is (at least partially) my fault, I don't mind being the first on the bandwagon. Particularly since my life seems to have taken a direction such that hacking on Calendar modules, however much I might want to do it, has to take a back seat to other things. I will try to figure out exactly what modules are mine and try to work out the best way to get these over into DateTime CVS. Will there be another tree in CVS for old modules (ie, those not conforming to the new namespace rules) until such time as the migrate to the new namespace, or become a thin wrapper around something in the new namespace, or ... something? -- Nothing is perfekt. Certainly not me. Success to failure. Just a matter of degrees.
ANNOUNCE: DateTime 0.09
No particular reason for this release, just an accumulation of improvements and fixes. 0.09 2003-04-05 (the liberation through violence release) [IMPROVEMENTS] - As requested by numerous people, there is now a pure Perl implementation of DateTime.pm included with this distribution. If you don't have a C compiler it will be used instead of the XS implementation. - Document how floating time zones are handling in comparisons, and add the compare_ignore_floating method. Based on a patch from Eugene van der Pijll. - Allow from_epoch(), now(), and today() to accept a time_zone parameter. Based on suggestions from Tim Bunce and Joshua Hoblitt. - Allow extraction of AM/PM string list from DateTime::Language classes. - Added quarter() and day_of_quarter() methods. Based on a patch from Tim Allwine. [BUG FIXES] - If a datetime had the floating timezone and then set_time_zone was used to set it to something else, the internal UTC time of the object was not changed, meaning that its offset could be calculated incorrectly. Patch by Eugene van der Pijll. - If datetime math was done with hours, minutes, or seconds, the return value of -epoch would be wrong after this. Based on report and patch from Iain Truskett. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration compare
Dave Rolsky wrote: I thought about this a bit more and realized I don't really like it, because it special cases one number, zero. But comparing it to other numbers wouldn't make sense. Ok. Maybe a $dt_dur-is_zero() method instead? - Flavio S. Glock
Re: DateTime::Duration, length of a month?
On Sat, 5 Apr 2003 12:05:15 +0200, [EMAIL PROTECTED] wrote: Joshua Hoblitt schreef: When converting a DateTime::Duration month to days - how many days should it be considering equivalent too? 30? 30.4? 31? If you want to do this, you have to take into account that a duration of $x years is translated to 12*$x years internally. If your calendar has ^ assume you mean months here no months, it should calculate the number of days to add as $delta_days + int( $delta_months * $DAYS_IN_YEAR/12 ); Problem with the Mayan calendar: it has no years either... But one of the smaller counts (haab) is 365 days long, I believe. So that is probably the Mayan idea of a year. (As usual) I disagree with Dave: some people would find it useful to use durations in any calendar, so why not implement them. As long as they use days and years only, there is no problem. And if they try to add a number of months to a Mayan date, they shouldn't complain about the result. I think I wrote the part of Date::Ical that originally did the x years = 12*x months translation, and I repent. A duration object should not merge its creating parameters into just seconds, days, and months buckets. This is much to Gregorian-centric.
