Re: DateTime.pm 0.30 coming up real soon now
Dave Rolsky wrote: I will make a list of all the problems I've run across so far, along with examples that demonstrate them. Anyone who can come up with a solution that handles all of these problems is a far smarter person than I am ;) It might already be out there...but can you wikifi it as well, please? I've been involved/lurking for quite a while now and though I could produce a few of these entries I still cannot rattle them off from memory. And for the list...perl makes the easy things easy and the hard things possible, as the saying goes...date math is easy. Absolute time is easy. Dates with times is hard, but so is visual cognition. :) Matt
Re: DateTime.pm 0.30 coming up real soon now
On Wed, 7 Sep 2005, Matt Sisk wrote: Dave Rolsky wrote: I will make a list of all the problems I've run across so far, along with examples that demonstrate them. Anyone who can come up with a solution that handles all of these problems is a far smarter person than I am ;) It might already be out there...but can you wikifi it as well, please? I've been involved/lurking for quite a while now and though I could produce a few of these entries I still cannot rattle them off from memory. Having a wiki would make this easier ;) I'll look for a place to set one up. And for the list...perl makes the easy things easy and the hard things possible, as the saying goes...date math is easy. Absolute time is easy. Dates with times is hard, but so is visual cognition. :) Actually, even date math isn't all that easy. -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: Having a wiki would make this easier ;) I'll look for a place to set one up. I'm happy to host one (something with auth and good perl rendering) at http://datetime.isite.net.au/ if you'd like. Cheers! Rick Measham
Re: DateTime.pm 0.30 coming up real soon now
On Wed, 7 Sep 2005, Rick Measham wrote: Dave Rolsky wrote: Having a wiki would make this easier ;) I'll look for a place to set one up. I'm happy to host one (something with auth and good perl rendering) at http://datetime.isite.net.au/ if you'd like. I realized that datetime.perl.org is now on its on virtual machine so I'll just stick a kwiki up there tomorrow. -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, Sep 06, 2005 at 09:57:11AM -0500, Dave Rolsky wrote: On Mon, 5 Sep 2005, Joshua Hoblitt wrote: If I understand you correctly, your position is that user's will be confused by DST transitions screwing up additions but won't notice the same effect on subtractions? No, they'll notice, but the workarounds for subtractions are well-documented. So why is that better than making subtractions work 'as expected' and documenting the work arounds for addition? Anyway, your position seemed to be that they won't notice for either, and that both should be weird ;) My position is that you really need to put on your critical thinking hat and think about how *wrong* it is for additions and subtractions to have different behaviors. The more I think about this the more I'm convinced that the idea of datetime subtraction producing something other than seconds is a convenient fiction. Similarly, date subtraction producing something other than a count of days is full of potential bugs. The whole point of DT is that it is *correct*. We need to decide on what the correct behavior is regardless of how painful it is to implement on top of the Rata Die system. It seems to me the real question would should be answering is: is calendar math subject to DST transitions or not? -J -- pgpIFCtNBcCT9.pgp Description: PGP signature
Re: DateTime.pm 0.30 coming up real soon now
Dave Rolsky wrote: 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. Ahh, cool 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. Yes I do don't I :) Thanks for putting up with my mumblings .. Is there a third time-only also? (I guess with no limit on hours) Cheers! Rick Measham
Re: DateTime.pm 0.30 coming up real soon now
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? -J -- pgppWjabm1uPy.pgp Description: PGP signature
Re: DateTime.pm 0.30 coming up real soon now
On Mon, Sep 05, 2005 at 11:49:33PM -0500, Dave Rolsky wrote: 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. If I understand you correctly, your position is that user's will be confused by DST transitions screwing up additions but won't notice the same effect on subtractions? -J -- pgpBdDrTSMYPC.pgp Description: PGP signature
Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, Rick Measham wrote: 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. Yes I do don't I :) Thanks for putting up with my mumblings .. Is there a third time-only also? (I guess with no limit on hours) Probably, just for the sake of completeness. It's certainly something that's simple enough to write. -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 11:49:33PM -0500, Dave Rolsky wrote: 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. If I understand you correctly, your position is that user's will be confused by DST transitions screwing up additions but won't notice the same effect on subtractions? No, they'll notice, but the workarounds for subtractions are well-documented. Anyway, your position seemed to be that they won't notice for either, and that both should be weird ;) The more I think about this the more I'm convinced that the idea of datetime subtraction producing something other than seconds is a convenient fiction. Similarly, date subtraction producing something other than a count of days is full of potential bugs. I'm thinking of addind a new section to the FAQ about all this after 0.30 is out. -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
I have been following this list primarily to learn. Let me say that I am a total newbie I know that I am stepping into a puddle that is way over my head. I am an occasional user of the datetime. Like most users regarding documentation When all else fails, read the manual I would like to present the needs of an occasional user...not necessarily a typical user. I primarily need to work with dates and I am not overly concerned with time. The results should be obviously correct and not throw an unexpected curve. When I find the difference between 2 dates I expect to obtain the same dates when I add/subract the difference. If I don't then it raises a red flag on the correctness of adding/ subtracting date duration...no matter what the documentation says. I understand the difficulty when adding/subtracting months July 4 - 1 month expect June 4 June 4 + 1 month expect July 4 July 31 - 1 month expect June 30 June 30 + 1 month expect July 30 However if I take the difference between 2 dates I definitely expect to obtain the original end dates. I don't want to dig through the documentation to find why it doesn't. I can understand the disruptions caused by various time periods year - 365/366 days month - 28/29, 30, 31 days I know that time zones and daylight saving time create their own difficulties. If I had to work with dates manually I would most probably not concern myself with time zones and daylight saving I do not presume to have any solution. I just ask that the developers come up with a KISS (keep it simple, I am stupid) module Perhaps a DateTime::SimpleDate would be what an occasional user like me would need Thank you for your indulgence. - Original Message - From: Dave Rolsky [EMAIL PROTECTED] To: datetime datetime@perl.org Sent: Tuesday, September 06, 2005 10:55 AM Subject: Re: DateTime.pm 0.30 coming up real soon now On Tue, 6 Sep 2005, Rick Measham wrote: 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. Yes I do don't I :) Thanks for putting up with my mumblings .. Is there a third time-only also? (I guess with no limit on hours) Probably, just for the sake of completeness. It's certainly something that's simple enough to write. -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, renard wrote: The results should be obviously correct and not throw an unexpected curve. When I find the difference between 2 dates I expect to obtain the same dates when I add/subract the difference. If I don't then it raises a red flag on the correctness of adding/ subtracting date duration...no matter what the documentation says. I understand the difficulty when adding/subtracting months July 4 - 1 month expect June 4 June 4 + 1 month expect July 4 July 31 - 1 month expect June 30 June 30 + 1 month expect July 30 However if I take the difference between 2 dates I definitely expect to obtain the original end dates. I don't want to dig through the documentation to find why it doesn't. I'm not quite following this paragraph. In the second example (July - June - July) are you saying those results are what you'd expect or not? If they're not what you'd expect, what would you expect instead? Perhaps a DateTime::SimpleDate would be what an occasional user like me would need The problem is (I think) that different people will have different expectations of what's intuitive here, because if you think about it much you realize that _almost nothing_ is intuitive when it comes to date(time) math. -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 said: The more I think about this the more I'm convinced that the idea of datetime subtraction producing something other than seconds is a convenient fiction. Similarly, date subtraction producing something other than a count of days is full of potential bugs. I agree .. let DateTime::Duration just result in these two units so that: Date - Date = d Days Time - Time = s Seconds DateTime - DateTime = (Date - Date) + (Time - Time) = d Days + s Seconds Of course, then there's the normalization question: 2005-09-10T12:54 - 2005-09-09T12:57 = a) 1 days, -180 seconds b) 86397 seconds Previously I campaigned for no mixing of negative/positive values in durations, but now I'd prefer the first option. That way, DST won't matter so much. On DST change-over I can still add 1 day, -180 seconds to 12:57 and end up on the next day at 12:54. With the second option I'd end up at 1:54 or 11:54. I guess the first option is the equivelent of the 'Local' arithmetic and the second is the equiv of UTC arithmetic. If we limit durations to these two units (days, seconds) then everything else can be done in DT:F:Duration... You have 30 days, your base is November 1st, the number of 'months' in this duration is 1. It's December 1st, there's zero months.. I'm not campaigning to see a Duration limited to these two units, just a substraction resulting in them. A duration can have 3 months, 1 hour. DT:F:Duration will be able to do a 'normalize' without any parsing/formatting which will mean that our 30 days from Nov 1st can be turned into a Month if that's what you tell DT:F:Duration that's how you want it. Cheers! Rick Measham
Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, Joshua Hoblitt wrote: No, they'll notice, but the workarounds for subtractions are well-documented. So why is that better than making subtractions work 'as expected' and documenting the work arounds for addition? Because AFAICT subtractions just _cannot_ work as expected. I have yet to see anyone come up with a proposal that fully accounts for DST changes. Anyway, your position seemed to be that they won't notice for either, and that both should be weird ;) My position is that you really need to put on your critical thinking hat and think about how *wrong* it is for additions and subtractions to have different behaviors. Well, they don't if you use either subtract_datetime_absolute (which is seconds only) or delta_days. Both of these return durations that work regardless of issues related to DST, ordering of add/subtract operations, etc. The more I think about this the more I'm convinced that the idea of datetime subtraction producing something other than seconds is a convenient fiction. Similarly, date subtraction producing something other than a count of days is full of potential bugs. The whole point of DT is that it is *correct*. We need to decide on what the correct behavior is regardless of how painful it is to implement on top of the Rata Die system. It seems to me the real question would should be answering is: is calendar math subject to DST transitions or not? Suggestions welcome, but I don't think you've thought of all the possible problems. The idea that DT.pm will always be correct is nice, but I don't think there is any one definition of correct in this area. I can imagine various insanely complicated attempts to make it all just work, but I suspect they'd be a house of cards. I will make a list of all the problems I've run across so far, along with examples that demonstrate them. Anyone who can come up with a solution that handles all of these problems is a far smarter person than I am ;) -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 Wed, 7 Sep 2005 [EMAIL PROTECTED] wrote: Dave Rolsky said: The more I think about this the more I'm convinced that the idea of datetime subtraction producing something other than seconds is a convenient fiction. Similarly, date subtraction producing something other than a count of days is full of potential bugs. I agree .. let DateTime::Duration just result in these two units so that: Date - Date = d Days Time - Time = s Seconds DateTime - DateTime = (Date - Date) + (Time - Time) = d Days + s Seconds Of course, then there's the normalization question: 2005-09-10T12:54 - 2005-09-09T12:57 = a) 1 days, -180 seconds b) 86397 seconds Previously I campaigned for no mixing of negative/positive values in durations, but now I'd prefer the first option. That way, DST won't matter so much. On DST change-over I can still add 1 day, -180 seconds to 12:57 and end up on the next day at 12:54. With the second option I'd end up at 1:54 or 11:54. This is somewhat appealing. Of course, you're still depending on a certain ordering of additions (days before seconds), I think. The fact that the ordering is fixed still creates situations where operations are not reversible. And yes, I know you've suggested offering many orderings, but that just means that users have to understand all of them and determine which one to use for every case, which basically translates to unusability. I guess the first option is the equivelent of the 'Local' arithmetic and the second is the equiv of UTC arithmetic. I guess. You didn't say which timezone, but I'm guessing Australia/Melbourne. If we limit durations to these two units (days, seconds) then everything else can be done in DT:F:Duration... You have 30 days, your base is November 1st, the number of 'months' in this duration is 1. It's December 1st, there's zero months.. I'm not campaigning to see a Duration limited to these two units, just a substraction resulting in them. A duration can have 3 months, 1 hour. DT:F:Duration will be able to do a 'normalize' without any parsing/formatting which will mean that our 30 days from Nov 1st can be turned into a Month if that's what you tell DT:F:Duration that's how you want it. Yeah, having subtraction return just these units, _and_ allowing mixed durations, does seem appealing given the alternatives. It allows for subtraction to follow the same mixed UTC/local logic as add_duration, which is cool, and I think it makes the endpoint +/- duration = other endpoint formula hold true in all cases. The downside is it's a semi-radical change to existing behavior, and basically forces the use of DT::Format::Duration to get what you current get. But that's not so bad, I guess. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
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 ===*/
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: 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 ===*/
