On 28/07/2015 16:47, Chris Angelico wrote:
On Tue, Jul 28, 2015 at 10:06 PM, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
On 28/07/2015 06:21, Lennart Regebro wrote:
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence <breamore...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
