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
