On 28/07/2015 16:47, Chris Angelico wrote:
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence
wrote: On 28/07/2015 06:21, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence
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