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
