DateTime.pm 0.30 coming up real soon now
So I have it to a state where I'm pretty happy with the code and docs. It won't satisfy everyone, but that's more or less impossible given how many correct ways of doing datetime math I've come up with. Here's the summary: - Adding a duration contains to work the same way as it always did, adding calendar bits (months days) to the local date, and time bits to the utc time. This generally just works as people expect and I haven't heard many complaints about it. - The subtract_datetime() method now does all its math on the UTC representation of the datetimes (unless they're floating). This is the sanest solution I could think of given the fact that any unit has to be convertible to any other unit to get a reasonable result (cause if you subtract hour 23 from hour 0, you pull a day off the object with hour 23). This means that if you do subtract_datetime on two objects you end up with this situation: $dur = $dt2 - $dt1 $dt1 + $dur != $dt2 $dt2 - $dur != $dt1 But honestly I don't really think that's a bug, and it's covered in the docs. - I updated the docs quite a bit to try to cover all the weird cases, particularly the ones that occur when you do math on an object in a DST-using time zone. I tested the new version with all the Calendar Event modules in the DT CVS repo, and they all passed. However, DateTime::Format::Duration from CPAN does not pass. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm 0.30 coming up real soon now
On Mon, 5 Sep 2005, Dave Rolsky wrote: I tested the new version with all the Calendar Event modules in the DT CVS repo, and they all passed. However, DateTime::Format::Duration from CPAN does not pass. Oops, meant to write more. Rick, I took a look at the code where it's failing and I'm not sure I understand it well enough to fix it. It's definitely related to the change in subtract_datetime() (forcing UTC) but I'm not sure how to either fix the code to make the tests pass, or if maybe the tests encode some incorrect assumptions. Either way, it looks like the code assumes that subtract_datetime and add_duration are inverse operations, but they're really not, and I don't think they ever were in the past, it's just that in the past different things might've been broken. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
ICal recurrence help wanted
Hi I am using the DateTime::Event::ICal-recur() function to calculate recurrences and whether the rpesent date/time lies in the recurrence. To state simply, my start and end dates as well as the recurrence are declared as follows: my $dt = DateTime-new( year = 2005, month = '08', day= 29, hour= 15, minute = 05, second = 00 ); my $end = DateTime-new( year = 2005, month = 11, day= 27, hour= 16, minute = 25, second = 00 ); my $set = DateTime::Event::ICal-recur( dtstart = $dt, freq ='secondly', interval = 1, byday = [mo], dtend = $end ); And this is what I need to check my $bool = $set-contains( DateTime-now() ); As of this writing, DateTime-now() returns 20050905T162355 in the ICal format and the day is Monday. I have two questions to ask here: 1) The bool value returned is FALSE whereas I believe it should be true. 2) Without the byday and interval arguments, the bool value is TRUE. Are these arguments causing issues? Appreciate any help in this regard. Many thanks -Chiradeep
Re: ICal recurrence help wanted
This may be a bug - I think byday=[mo] causes hour/min/second to be zero. I'll test this. - Flavio S. Glock 2005/9/5, Chiradeep Chhaya [EMAIL PROTECTED]: Hi I am using the DateTime::Event::ICal-recur() function to calculate recurrences and whether the rpesent date/time lies in the recurrence. To state simply, my start and end dates as well as the recurrence are declared as follows: my $dt = DateTime-new( year = 2005, month = '08', day= 29, hour= 15, minute = 05, second = 00 ); my $end = DateTime-new( year = 2005, month = 11, day= 27, hour= 16, minute = 25, second = 00 ); my $set = DateTime::Event::ICal-recur( dtstart = $dt, freq ='secondly', interval = 1, byday = [mo], dtend = $end ); And this is what I need to check my $bool = $set-contains( DateTime-now() ); As of this writing, DateTime-now() returns 20050905T162355 in the ICal format and the day is Monday. I have two questions to ask here: 1) The bool value returned is FALSE whereas I believe it should be true. 2) Without the byday and interval arguments, the bool value is TRUE. Are these arguments causing issues? Appreciate any help in this regard. Many thanks -Chiradeep
Re: DateTime.pm 0.30 coming up real soon now
Dave Rolsky wrote: Rick, I took a look at the code where it's failing and I'm not sure I understand it well enough to fix it. It's definitely related to the change in subtract_datetime() (forcing UTC) but I'm not sure how to either fix the code to make the tests pass, or if maybe the tests encode some incorrect assumptions. Either way, it looks like the code assumes that subtract_datetime and add_duration are inverse operations, but they're really not, and I don't think they ever were in the past, it's just that in the past different things might've been broken. Duration needs an overhaul, but I was waiting for you to finish the DT stuff first. The tests used to pass even if I assumed something weird .. Its good that they're not passing now as it will help me learn why not! Once 0.30 is out, I'll put some effort into DT:F:D however it won't be this weekend as my wife has booked a holiday for the weekend and she'll be mildly annoyed if I work on DateTime :) Thanks for your efforts Dave! Cheers! Rick Measham
Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, Rick Measham wrote: Once 0.30 is out, I'll put some effort into DT:F:D however it won't be this weekend as my wife has booked a holiday for the weekend and she'll be mildly annoyed if I work on DateTime :) Cool, just wanted to give you a heads up that it'd break your code. I'll release 0.30 later this week. If people want to look over what's in CVS, and in particular read the new docs on datetime math, that'd be nice. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm 0.30 coming up real soon now
On Mon, 5 Sep 2005, Joshua Hoblitt wrote: On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote: This means that if you do subtract_datetime on two objects you end up with this situation: $dur = $dt2 - $dt1 $dt1 + $dur != $dt2 $dt2 - $dur != $dt1 But honestly I don't really think that's a bug, and it's covered in the docs. I think that behavior would merely be a documented bug and worse a support nightmare. I can not logically grasp how the internal between two known fixed points on a continuing would have not have a well known distance between them. Won't forcing add_duation() to convert to UTC resolve this inconsistency? It would, but then add_duration() would produce very confusing results for other things: my $dt = DateTime-new( year = 2003, month = 9, time_zone = 'America/Chicago' ); $dt-add( months = 3 ); Now what do you expect that to produce? I suspect 99% of users expect that to produce 2003-12-01T00:00:00. In other words, we take month 9, add 3, and get 12. The time remains untouched. But if add_duration did the math on the UTC portions it'd give you 2003-11-30T23:00:00. I suspect that'd generate a much greater number of bug reports. I think what I've come up with is the best solution. I tried to get subtract_datetime to do the mixed local/UTC thing add_duration does, but I could not get it to work sanely. I might take another crack at it if others object, but I think that the current (in repo) behavior is at least predictable, accurate, and reasonably sane (and documented). -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm 0.30 coming up real soon now
Dave Rolsky wrote: This means that if you do subtract_datetime on two objects you end up with this situation: $dur = $dt2 - $dt1 $dt1 + $dur != $dt2 $dt2 - $dur != $dt1 So, assuming America/Chicago: (2003-12-01) - (2003-09-01) will return a duration representing 2 months, 29 days and 23 hours? If so, I'd prefer it returned a duration object representing n seconds ... THEN I'd like to see another 'local difference' function that worked down from years .. 2003 - 2003 = 0 years 12 - 09 = 3 months 01 - 01 = 0 days (extending .. (2004-01-23) - (2003-09-01) becomes: 2004 - 2003 = 1 year \auto normalises/ 0 years 01 - 09 = -8 months -- to get rid of -- 4 months 23 - 01 = 22 days /negative values\ 22 days ) Then again, I wonder if durations shouldn't be removed altogether and put into separate packages that allowed people to choose their math assumptions. Cheers! Rick Measham
Re: ICal recurrence help wanted
Also, Consider the case where an event starts at midnight, the DURATION is 1H (or the DTEND is 1 hour beyond DTSTART) and the event recurs, say daily. Now, if I set the recur frequency to daily with the dtstart an dtend set according to this span of one hour and the appropriate dates, the recur-contains value returned is FALSE. E.g. if DTSTART is 20050906T00, DTEND is 20050906T01, UNTIL=20050920T045959Z, FREQ=DAILY and DateTime-now() is 20050906T005812, shouldn't this be contained in the recurrence? I am handling the dtend for the DateTime::Event::ICal-recur appropriately using the time from DTEND and date from UNTIL. Thanks. -Chiradeep On 05-Sep-05, at 6:16 PM, Flavio S. Glock wrote: This may be a bug - I think byday=[mo] causes hour/min/second to be zero. I'll test this. - Flavio S. Glock 2005/9/5, Chiradeep Chhaya [EMAIL PROTECTED]: Hi I am using the DateTime::Event::ICal-recur() function to calculate recurrences and whether the rpesent date/time lies in the recurrence. To state simply, my start and end dates as well as the recurrence are declared as follows: my $dt = DateTime-new( year = 2005, month = '08', day= 29, hour= 15, minute = 05, second = 00 ); my $end = DateTime-new( year = 2005, month = 11, day= 27, hour= 16, minute = 25, second = 00 ); my $set = DateTime::Event::ICal-recur( dtstart = $dt, freq ='secondly', interval = 1, byday = [mo], dtend = $end ); And this is what I need to check my $bool = $set-contains( DateTime-now() ); As of this writing, DateTime-now() returns 20050905T162355 in the ICal format and the day is Monday. I have two questions to ask here: 1) The bool value returned is FALSE whereas I believe it should be true. 2) Without the byday and interval arguments, the bool value is TRUE. Are these arguments causing issues? Appreciate any help in this regard. Many thanks -Chiradeep
Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, Rick Measham wrote: So, assuming America/Chicago: (2003-12-01) - (2003-09-01) will return a duration representing 2 months, 29 days and 23 hours? Yes, _but_ the docs suggest that if you don't like this you probably wanted _date_ math (not datetime) in the first place, and you can use delta_md(), which will return 3 months. If so, I'd prefer it returned a duration object representing n seconds ... THEN I'd like to see another 'local difference' function that worked down from years .. 2003 - 2003 = 0 years 12 - 09 = 3 months 01 - 01 = 0 days (extending .. (2004-01-23) - (2003-09-01) becomes: 2004 - 2003 = 1 year \auto normalises/ 0 years 01 - 09 = -8 months -- to get rid of -- 4 months 23 - 01 = 22 days /negative values\ 22 days ) Examples that are date only are pretty meaningless. You can already get the results you're suggesting with the delta_md() method. The complication is when you add in times to the mix. Once you do that it gets really messy, especially if you're trying to produce a duration that consists of all positive or negative deltas. Then again, I wonder if durations shouldn't be removed altogether and put into separate packages that allowed people to choose their math assumptions. You always suggest splitting it up into more packages, but that doesn't necessarily help. I think the real problem here is that a lot of people just want date math, and they don't care about times. The real split should probably be a date-only module vs a date+time module. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, Dave Rolsky wrote: Then again, I wonder if durations shouldn't be removed altogether and put into separate packages that allowed people to choose their math assumptions. You always suggest splitting it up into more packages, but that doesn't necessarily help. I think the real problem here is that a lot of people just want date math, and they don't care about times. The real split should probably be a date-only module vs a date+time module. I'd also point out that if we offer all the possible math combos, people would have to read even more docs, think about this even harder, and still would get things wrong and be confused. If DT.pm provides some sort of default, however arbitrary, they can at least count on that and use it to get their work done. There are various workarounds that can be used to achieve any results desired, and people who really need that will be able to figure out how to do what they want (probably with help from this list). But for the vast majority of folks, they can follow the new guidelines in the docs and get useful results without having to understand too much of the details, which is what I've always aimed for with this module, since understanding _all_ the details is really quite a lot of work. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
