[Python-Dev] Status on PEP-431 Timezones

[Mark Lawrence]

On 28/07/2015 16:47, Chris Angelico wrote:
> On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>> On 28/07/2015 06:21, Lennart Regebro wrote:
>>>
>>> On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamoreboy at yahoo.co.uk>
>>> wrote:
>>>>
>>>> To me a day is precisely 24 hours, no more, no less.
>>>> In my mission critical code, which I use to predict my cashflow, I use
>>>> code such as.
>>>>
>>>> timedelta(days=14)
>>>>
>>>> Is somebody now going to tell me that this isn't actually two weeks?
>>>
>>>
>>> Yes, I'm telling you that, now.
>>>
>>> The two claims "One day is always precisely 24 hours" and "14 days is
>>> two weeks" are not both true. You have to choose one.
>>
>> You can tell me, but as far as I'm concerned in my application both are
>> true, so I don't have to choose one.
> (and subsequently)
>> Tim asked for my definition of two weeks so I've given it.  With respect
>> to that in reality this is true, for me, with my application, making my
>> statement above correct.  For my application we could go from GMT
>> to BST and back on successive days throughout the year and it
>> wouldn't make any difference.
>
> When your clocks go from winter time to summer time, there are two
> possibilities:
>
> 1) Your application says "days=14" and actually gets 167 or 169 hours
> 2) Your application says "days=14" and ends up with the time changing

My cashflow forecast doesn't give two hoots how many hours there are in 
two weeks, which I've defined elsewhere.  It doesn't care if the time 
changes.  Neither does it care how many days there are in a month for 
that matter.  It can even cater with plotting data with a tick on the 
29th of each month when we have a leap year and February is included in 
the plot, thanks to the dateutils rrule.

>
> (Or equivalently if you say "days=1" or "hours=24" or whatever.)
>
> A naive declaration of "two weeks later" could conceivably mean
> either. When I schedule my weekly Dungeons & Dragons sessions, they
> are officially based on UTC [1], which means that one session starts
> 168 hours after the previous one. Currently, they happen when my local
> clock reads noon; in summer, my local clock will read 1PM. Was it
> still "a week later" when it was noon once and 1PM the next time?

Don't know and don't care, your application is not working in the same 
way that mine does.

>
> Conversely, my (also weekly) Thinkful open sessions are scheduled
> every week at 8AM US Eastern time (America/New_York). For anyone on
> the Atlantic coast of the US, they will occur every Wednesday and the
> clock will read 08:00 every time. Sometimes, one will happen 167 hours
> after the previous one, or 169 hours afterwards. Is that "a week
> later"?

Ditto my above remark.

>
> Your application has to make a choice between these two
> interpretations. This is a fundamental choice that MUST be made.
> Trying to pretend that your application doesn't care is like trying to
> say that Code Page 437 is good enough for all your work, and you can
> safely assume that one byte is one character is one byte.
>

No.

> ChrisA
>
> [1] Leap seconds aren't significant, as people are often several
> minutes early or late, so UTC/UT1/GMT/TIA are all effectively
> equivalent.
>

Precisely my point.  For me hours are not significant, days are.
-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence