New submission from Alexander Belopolsky belopolsky@users.sourceforge.net:
I am opening this to supersede issue7229. See discussion following msg107148.
In many places offsets representing the difference between local time and UTC are described as minutes or seconds east or west of UTC. This is not correct because UTC is not a place and minutes and seconds don't measure distance in this context. Replacing UTC with the Prime Meridian will not fix that because some regions in the western hemisphere use positive offsets from UTC. or example, Madrid is at 3° 42' West, but uses Central European Time which is UTC+1.
I believe geographical references in the python documentation are irrelevant. What users are interested in is how to convert local time to UTC and UTC to local time rather than what is the sign of time.timezone in Madrid.
I suggest the following wording for time.timezone description:
time.timezone: The number of seconds one must add to the local time to arrive at UTC.
Similarly, tzinfo.utcoffset() can be defined as "Returns timedelta one must add to UTC to arrive at local time."
---------- assignee: docs@python components: Documentation keywords: easy messages: 110774 nosy: belopolsky, docs@python priority: normal severity: normal stage: needs patch status: open title: Don't use east/west of UTC in date/time documentation type: feature request versions: Python 3.2
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Changes by Alexander Belopolsky belopolsky@users.sourceforge.net:
---------- dependencies: +Manual entry for time.daylight can be misleading
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
On Mon, Jul 19, 2010 at 7:21 PM, Alexander Belopolsky report@bugs.python.org wrote:
I suggest the following wording for time.timezone description:
time.timezone: The number of seconds one must add to the local time to arrive at UTC.
Makes sense. I can't see any other real explanation for -7200 value if I am in +2 UTC timezone.
Similarly, tzinfo.utcoffset() can be defined as "Returns timedelta one must add to UTC to arrive at local time."
I believe the correct convention is "Return timedelta...". Another concern - if UTC is 0 reference point then there is no reason to add something to it - you just can say - "Return timedelta equal to local UTC offset."
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
On Tue, Jul 20, 2010 at 10:46 AM, anatoly techtonik report@bugs.python.org wrote:
.. Another concern - if UTC is 0 reference point then there is no reason to add something to it - you just can say - "Return timedelta equal to local UTC offset."
No, UTC is not a 0 reference point, it is a time scale. UTC offset is the value that is used to translate between time expressed in UTC and local time. To make an analogy, expressing time in UTC is like expressing temperature in Kelvin scale. You need to subtract 273 from the value in ºK to arrive at the value in ºC.
Documenting utcoffset() as "Return timedelta equal to local UTC offset." is almost circular. It does not explain whether it has to be added or subtracted from UTC to arrive at local time.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Tim Peters tim.peters@gmail.com added the comment:
FYI, I like the change. As I recall it, the current wording was just to avoid saying "ahead of UTC" or "behind UTC" (which was the original wording). Technically pure or not, I never saw anyone get truly confused by "East of UTC" or "West of UTC", but I fully that what people really want to know is what to do with the thing (add or subtract it).
---------- nosy: +tim_one
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
On Tue, Jul 20, 2010 at 10:46 AM, anatoly techtonik techtonik@gmail.com wrote:
I believe the correct convention is "Return timedelta...".
This is handled inconsistently in the documentation; I'm hoping the current maintainers reinforce the "Returns ..." structure. The documentation is descriptive, not an external specification.
-Fred
-- Fred L. Drake, Jr. <fdrake at gmail.com> "A storm broke loose in my mind." --Albert Einstein
anatoly techtonik techtonik@gmail.com added the comment:
Documenting utcoffset() as "Return timedelta equal to local UTC offset." is almost circular. It does not explain whether it has to be added or subtracted from UTC to arrive at local time.
Ok. Sold.
I believe the correct convention is "Return timedelta...".
This is handled inconsistently in the documentation; I'm hoping the current maintainers reinforce the "Returns ..." structure. The documentation is descriptive, not an external specification.
http://www.python.org/dev/peps/pep-0257/#one-line-docstrings
I've took the convention from here. I thought docs are generated from docstrings.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Fred L. Drake, Jr. fdrake@acm.org added the comment:
On Tue, Jul 20, 2010 at 12:08 PM, anatoly techtonik report@bugs.python.org wrote:
I've took the convention from here. I thought docs are generated from docstrings.
They're not, but I don't think that really matters.
Older documentation used the imperative form consistently, but that's shifted over time. (I, at least, think that's a good thing.)
I don't think it really matters with regard to this issue.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
On Tue, Jul 20, 2010 at 11:39 AM, Tim Peters report@bugs.python.org wrote:
.. As I recall it, the current wording was just to avoid saying "ahead of UTC" or "behind UTC" (which was the original wording).
Interesting. I actually like the original wording better. For me, "my watch is 6 hours behind UTC" makes it clear that when the Big Ben clock shows tea time (18:00), my watch displays noon (17:00 - 6:00 = 12:00.)
I wonder if east/west is somehow more natural for native speakers of English. I would really like to hear more from the international audience. When it comes to measuring time there are many interesting traditions that don't translate well between nations. For example, I've heard that in the Far East, the future is considered to be behind because you can see the past but you cannot see the future. If this is the notion that you are used to, time being ahead or behind can be truly confusing.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
On Tue, Jul 20, 2010 at 12:14 PM, Alexander Belopolsky report@bugs.python.org wrote: ..
Interesting. I actually like the original wording better. For me, "my watch is 6 hours behind UTC" makes it clear that when the Big Ben clock shows tea time (18:00), my watch displays noon (17:00 - 6:00 = 12:00.)
I was too excited to add Alice in Wonderland humor to my post that did not get the math right. :-)
The above should read 18:00 - 6:00 = 12:00, of course. Or was it five o'clock after all?
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
On Tue, Jul 20, 2010 at 12:08 PM, anatoly techtonik report@bugs.python.org wrote: ..
Ok. Sold.
Good. All we need now is just a patch. :-)
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Changes by Rodrigo Bernardo Pimentel rbp@isnomore.net:
---------- nosy: +rbp
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Henrique Bastos henrique@bastos.net added the comment:
Here goes a patch to replace east/west references on datetime documentation.
As spoken with fdrake we think the datetime documentation could be improved extracting the timezone subclassing details to specific section. We'll be filling a new issue for that patch.
---------- nosy: +Rodolpho.Eckhardt, henriquebastos
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Henrique Bastos henrique@bastos.net added the comment:
Here goes a patch to replace east/west references on datetime documentation.
As spoken with fdrake we think the datetime documentation could be improved extracting the timezone subclassing details to specific section. We'll be filling a new issue for that patch.
---------- keywords: +patch Added file: http://bugs.python.org/file19694/datetime_doc_remove_east_west.diff
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
LGTM
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Changes by Alexander Belopolsky belopolsky@users.sourceforge.net:
---------- assignee: docs@python -> belopolsky stage: needs patch -> commit review
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
On the second reading, I have a few issues with the patch.
1. Please run makepatcheck. There are whitespace issues in datetime.rst. 2. In docstrings, you remove the information about the sign. I would not mind leaving docstrings the way they are. Otherwise, please add a short sentence explaining the sign of utcoffset and dst. 3. "This represents the offset in minutes that must be added to the local time zone to follow DST rules." This unclear. DST offset is added to the "standard time", not "local time zone". (I am not sure if "standard time" is defined in the manual, though.) Also, "in minutes" is not necessary - timedelta carries the units. You can add that only offsets that are multiples of a minute are supported.
---------- stage: commit review -> patch review
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Henrique Bastos henrique@bastos.net added the comment:
To clarify:
1) "we" means henriquebastos, rbp, Rodolpho.Eckhardt.
2) Mentioning fdrake I was trying to say that we followed his suggestion to only submit the specific changes on this patch, leaving further documentation changes to another issue.
Sorry about any inconvenience.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Rodrigo Bernardo Pimentel rbp@isnomore.net added the comment:
1. Done (it's on the patch I'm uploading). Sorry.
3. Ok, we've rewritten that sentence. As Henrique mentioned, we're working on a larger patch to make datetime documentation clearer, and we can include a definition of "standard time" there.
2. I assume you're talking about sentences like "(negative for west of UTC)". We removed that wording because it inevitably leads to associating UTC with a geographical reference. Even if we disregard that, it's not true that "utcoffset is negative west of UTC", since it will we zero for for UTC-1 (and even +1 for places physically "west of UTC" but at timezone UTC+0) when DST is effective.
It seems that any sentence we add to that effect will be simply restating the definitions of UTC, timezones and DST (and their mathematical relationships). That is, "utcoffset will be negative when dt.tzinfo + dst() is negative".
Perhaps we could include a more detailed discusion about the sign of utcoffset() on the larger doc patch I've mentioned? Or do you have any suggestions?
---------- Added file: http://bugs.python.org/file19709/datetime_doc_remove_east_west_2.diff
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky belopolsky@users.sourceforge.net added the comment:
I've noticed that the time module docstring handles this issue rather nicely:
help('time')
... timezone -- difference in seconds between UTC and local standard time altzone -- difference in seconds between UTC and local DST time
We can use similar language for utcoffset(): "difference between local time and UTC expressed as a timedelta".
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Mark Lawrence added the comment:
Well, we have a patch and it's been discussed here and on #7229, so can we take this forward?
---------- nosy: +BreamoreBoy
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Changes by Mark Lawrence breamoreboy@yahoo.co.uk:
---------- nosy: -BreamoreBoy
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Changes by Alexander Belopolsky alexander.belopolsky@gmail.com:
---------- dependencies: +Don't use east/west of UTC in date/time documentation
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Alexander Belopolsky added the comment:
This seems to be touching the same areas as #9305.
---------- assignee: belopolsky ->
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Martin Panter added the comment:
Assuming you meant Issue 8810, yes these patches would collide with each other. I am yet to look at the patches, but I gess they should be merged.
---------- dependencies: +TZ offset description is unclear in docs -Don't use east/west of UTC in date/time documentation nosy: +martin.panter
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue9305 _______________________________________
Cheryl Sabella chekat2@gmail.com added the comment:
Would one of the original authors of the patches like to create a GitHub pull request for this issue?
---------- nosy: +csabella
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue9305 _______________________________________
Change by Paul Ganssle p.ganssle@gmail.com:
---------- nosy: +p-ganssle
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue9305 _______________________________________
Ajay Mahato ajjayymahato@gmail.com added the comment:
I would like to work on this issue. Please assign this to me.
---------- nosy: +Ajay Mahato
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue9305 _______________________________________
Ajay Mahato ajjayymahato@gmail.com added the comment:
I am taking up this issue.
----------
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue9305 _______________________________________
Chris Wilcox python@crwilcox.com added the comment:
Are you still working on this Ajay Mahato?
---------- nosy: +crwilcox
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue9305 _______________________________________
Change by Murali Ravipudi murali.ravipudi@gmail.com:
---------- nosy: +Murali Ravipudi
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue9305 _______________________________________
-
Ajay Mahato -
Alexander Belopolsky
-
anatoly techtonik
-
anatoly techtonik -
Cheryl Sabella
-
Chris Wilcox
-
Fred Drake -
Fred L. Drake, Jr.
-
Henrique Bastos
-
Mark Lawrence
-
Martin Panter
-
Murali Ravipudi
-
Paul Ganssle
-
Rodrigo Bernardo Pimentel
-
Tim Peters