Re: API changes for date math (UTC vs local)
On Tue, 16 Aug 2005, Dave Rolsky wrote: On Tue, 16 Aug 2005, Eugene van der Pijll wrote: This suggests that the proper solution is not to have two methods, one for local subtraction and one for utc subtraction; but to do calculations with hours/mins/seconds in utc, and days/months/years in local time. No, it used to do that, but that caused complaints too ;) Actually, looking closer I think that this is correct for adding durations to datetimes. I need to come up with more test cases for datetime subtraction to figure out the best behavior. I'm working on this now and I'm doing it test first, with lots of comments, so that once I'm done I can turn this into documentation. More and more, I'm realizing that the calendar and the clock are two very different beasts, with a strange relationship. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: API changes for date math (UTC vs local)
On 8/16/05, Dave Rolsky [EMAIL PROTECTED] wrote: So it turns out that DT.pm has basically been buggy with regards to date math for any timezone with a DST change basically forever. The problem is that sometimes people want to do math in terms of the local time (the clock display time) and sometimes in terms of UTC time (the actual passing of time based on the atomic clock). [...] Ok, that's my summary of the proposed API changes. Feedback is very welcome. Any chance of the great dates without times vs. datetimes split happening in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of the DateTime::Incomplete stuff could help here? As for the particular proposed changes, I think the methods names don't clearly describe what's going on. When I see subtract_datetime_utc() I wonder if I have to pass a DateTime object with its timezone set to UTC or something. As I understand it, the distinction is actual (i.e., atomic) time that has passed versus local calendar/clock time that has passed. I do agree that local calendar/clock math should be the default, so that covers add(), subtract(), etc. But as for the other methods, I think the _utc suffix is confusing. UTC doesn't bring to (my) mind the actual time that has passed concept, even if that's how it's done internally. So, how about making add() and alias for add_calendar() or add_local(), and then have add_absolute() or maybe add_temporal() or something for the other style? I know that absolute is already used elsewhere in the API. If it doesn't mean the same thing here, then maybe a different word should be used. Temporal kind of stinks though. Ideas? -John
Re: API changes for date math (UTC vs local)
Dave Rolsky schreef:
But in fact, one hour less than 6 months has passed because of the DST
change
I think this is a very strange thing to say, as the duration 6 months
is never a fixed amount of hours, not even in UTC.
In this case, we added 6 months to the _UTC_ time and the displayed clock
time changes, due to DST. This is also a reasonable result, since it
reflects the actual amount of time that has passed.
I don't think it is reasonable, and I can't remember anyone complaining
about this. Can you give a reference? [*]
So what's the solution?
I think we need to have dual sets of methods, one for local and one for
UTC:
I don't like it. The proper solution IMHO would be to do the calculation
in utc, if that is what you want:
$localzone = $dt1-time_zone;
$dt1 = $dt1-set_timezone('utc')
-add_duration(months = 6)
-set_timezone($localzone);
It's not a common problem, as far as I can see, at least not for people
who work with local times. They (almost?) never want to account for
leap hours when subtracting datetimes in July and December, for
instance.
1 day is just not always the same as 24 hours, in timezones with DST.
That's how DateTime has always worked; that is how it should work.
Eugene
[*] According to the Changes file, the change to calculations in UTC was
prompted by a bug report by Mike Schilli. I can't find this report; do
you know what the problem was?
Re: API changes for date math (UTC vs local)
John Siracusa schreef: Any chance of the great dates without times vs. datetimes split happening in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of the DateTime::Incomplete stuff could help here? Dave, are you working on this for Perl 5? I've thought about this as well, partly because I want to create separate DateTime::Time modules, for example for TAI time, and metric time; and I want to be able to use those time scales with all calendars, so the date and the time part of the modules should be separated. Should I continue to work on this, or do you have concrete plans already in this direction (other than your Perl 6 modules). Eugene
Re: API changes for date math (UTC vs local)
On Tue, 16 Aug 2005, Eugene van der Pijll wrote: John Siracusa schreef: Any chance of the great dates without times vs. datetimes split happening in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of the DateTime::Incomplete stuff could help here? Dave, are you working on this for Perl 5? I've thought about this as well, partly because I want to create separate DateTime::Time modules, for example for TAI time, and metric time; and I want to be able to use those time scales with all calendars, so the date and the time part of the modules should be separated. Should I continue to work on this, or do you have concrete plans already in this direction (other than your Perl 6 modules). I have no concrete plans for Perl 5 stuff. I wanted to experiment with this in P6 because that way no one can complain when I repeatedly break backwards compatibility ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: API changes for date math (UTC vs local)
Dave Rolsky schreef: There have been several reports, they're in the list archives. One was from Mike Schilli. Then another more recent one complained about the change I made based on Mike's bug report. Can't win ;) I've found it now: http://www.nntp.perl.org/group/perl.datetime/5619 . Mike actually complained about a subtraction around a DST change, where the difference was less than a day: 2003-04-06T01:58:00 - 2003-04-06T03:01:00 . This returned 1h 3m, when the two dt's were just 3 minutes apart due to a DST change. In this case, doing the math on the UTC datetimes gives the most reasonable answer. This suggests that the proper solution is not to have two methods, one for local subtraction and one for utc subtraction; but to do calculations with hours/mins/seconds in utc, and days/months/years in local time. That's true, but it's a bit cumbersome. At the very least, offering some sort of convenience method for the above would be nice. If it's needed. Which for Mike's problem, it isn't. Actually, DateTime was doing some really weird stuff for a long time, mixing local and UTC times in the date math. As I said, mixing local and utc math would be correct, IMHO, although I'm not certain the previous implementation was the correct one. Eugene
Re: API changes for date math (UTC vs local)
John Siracusa wrote: As for the particular proposed changes, I think the methods names don't clearly describe what's going on. When I see subtract_datetime_utc() I wonder if I have to pass a DateTime object with its timezone set to UTC or something. As I understand it, the distinction is actual (i.e., atomic) time that has passed versus local calendar/clock time that has passed. I do agree that local calendar/clock math should be the default, so that covers add(), subtract(), etc. But as for the other methods, I think the _utc suffix is confusing. UTC doesn't bring to (my) mind the actual time that has passed concept, even if that's how it's done internally. So, how about making add() and alias for add_calendar() or add_local(), and then have add_absolute() or maybe add_temporal() or something for the other style? I like this idea and agree with John's first comment .. the '_utc' suffix doesn't really describe the effect, merely the process. If I have a localtime and I add_utc, I'd still get a localtime back. add_calendar() (aliased to add()) sounds like a good name for the old behaviour (local for ymd, UTC for hmsn) as we're adding according the the calender. I'm still trying to find some name for the current behaviour. My problem comes from why you'd want to use it .. if I really wanted 24 hours from now rather than 1 day from now I should be adding 24 hours. Which in the old system works just fine. If you're really interested in how many seconds there are between two dates, then I assume leap seconds will need to come into it also. I can't imagine there are many DT users who want to use it for this purpose. Those who do should be converting in and out of UTC themselves. Cheers! Rick Measham
Re: API changes for date math (UTC vs local)
On 8/16/05 8:01 PM, Rick Measham wrote: add_calendar() (aliased to add()) sounds like a good name for the old behaviour (local for ymd, UTC for hmsn) as we're adding according the the calender. I was thinking add_calendar() would be local for ymd and hmsn...but maybe I'm confused. Basically, as far as add_calendar() is concerned, add one day means point to the next box on the wall calendar, and add one hour means what time will it be one hour from now? This is all from the perspective of a local person. When we fall back in DST, for example, one hour from now will be, well, now (if we just consider the time). -John
