Re: [Datetime-SIG] naive DateTime, aware DateTime, precise DateTIme
[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@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
On Thu, Jul 30, 2015 at 2:00 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
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).
Exactly -- but that's really dangerous, actually, if something works "as expected" most of the time, people will blindly go about their business using it, and then get an ugly bug report way down the line (hopefully). 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.
There is a hug gap between "needs to be accurate to less than hour" and "nuclear power plants, flying planes" I for one, work all the time with datasets that, yes, SHOULD all be in UTC, but are often not, and I need to both accept input and return output in whatever timezone the user has/needs, and arithmetic had better be real, genuine 24 hours is 24 hours.... In fact, I can certainly see that some use cases call for Period Arithmetic (which I never need), but I can't image a use case that calls for Duration Arithmetic but doesn't care about an hour one way or the other! In practice, all my code does the time-zone conversion on I/O, keeping everything in naive datetimes internally (or unix tics -- ugg!) But it would be nice nice to have good, robust time-zone aware datetimes instead -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (2)
-
Chris Barker -
Ethan Furman