[Datetime-SIG] naive DateTime, aware DateTime, precise DateTIme

Ethan Furman ethan at stoneleaf.us
Thu Jul 30 23:00:58 CEST 2015


[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 <ethan at stoneleaf.us> 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


More information about the Datetime-SIG mailing list