[redirecting back to list]
On 07/30/2015 11:49 AM, Skip Montanaro wrote:
On Thu, Jul 30, 2015 at 1:33 PM, Ethan Furman <[email protected]> wrote:
Instead of making a new timedelta object, which, after all, represents
exactly what it says, why don't we make a new DateTime and Time that do the
duration arithmetic?
Anyone who wants that behaviour has to explicitly use the type so there
would be no backwards compatibility issues with the existing DateTime, Time,
or timedelta objects.
I'm sorry. I must surely have missed something. I freely admit having
mentally elided the datetime-related discussions on python-dev. Under
what circumstances (other than perhaps the grey areas around the
change in or out of daily savings, or intervals crossing leap seconds)
do the current types not perform as expected? Are there test cases
missing from the test suite which would fail using the current
implementation?
It is exactly those grey areas that have caused all the hullabaloo, and that's where 24 hours isn't (through no fault of timedelta). Using the example code from the datetime docs [1] as the base and
going forward:
--> my_time = datetime(2015, 3, 7, 13, 30, tzinfo=Pacific)
--> my_time.strftime('%H:%M %z')
'13:30 -0800'
--> (my_time + 24 * HOUR).strftime('%H:%M %z')
'13:30 -0700'
The actual duration of time between those two instances is not 24 HOURS, but the blame for that lies with datetime, not timedelta. So my thought is to either make an entirely new type, or have a
keyword argument, with the effect of a datetime that does account for dst switches:
# HYPOTHETICAL CODE, DOES NOT CURRENTLY WORK
--> my_time = datetime(2015, 3, 7, 13, 30, tzinfo=Pacific, precise=True)
--> my_time.strftime('%H:%M %z')
'13:30 -0800'
--> (my_time + 24 * HOUR).strftime('%H:%M %z')
'14:30 -0700' # assuming I did the math right in my head ;)
I must admit, though, I'm not sure how often such a class would be used -- if the application is important enough to be exact with the durations (nuclear power plants, flying planes, etc.) then I
would think a time zone such as UTC would be used just to avoid any possible confusion around those dst switches.
--
~Ethan~
[1] https://docs.python.org/3/library/datetime.html#datetime.tzinfo
_______________________________________________
Datetime-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/datetime-sig
The PSF Code of Conduct applies to this mailing list:
https://www.python.org/psf/codeofconduct/
