Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7229
___
Changes by Berker Peksag berker.pek...@gmail.com:
--
stage: patch review - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7229
___
___
Changes by Kenyon Ralph ken...@kenyonralph.com:
--
nosy: +kralph
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7229
___
___
Python-bugs-list
Tomas Kubes mr_na...@centrum.cz added the comment:
I am sorry, but as an original initiator of the the issue I find the
argumentation of Alexander Belopolsky vastly ridiculous. Are you really
seriously convinced that an average person responsible for Python application
development and
anatoly techtonik techto...@gmail.com added the comment:
Classic user developer impedance mismatch. =)
I agree that Python should guard its users against crazy standards that creep
into standard lib, because nobody had time to think about pythonic API.
I propose the following change:
Tomas Kubes mr_na...@centrum.cz added the comment:
Hello,
I find this version very clear.
Thanks
Tomas
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7229
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Jan 11, 2011 at 4:55 AM, anatoly techtonik
rep...@bugs.python.org wrote:
..
I propose the following change:
..
http://docs.python.org/library/time.html#time.daylight
- Nonzero if a DST timezone is defined.
+ ..
Tomas Kubes mr_na...@centrum.cz added the comment:
why do you think someone reading about
time.daylight actually wants to check if DST is currently active?
If you are not familiar with the cryptic names of POSIX but live in normal
world, time.daylight sounds like a quite probable place where
Changes by Brian Curtin cur...@acm.org:
--
nosy: -brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7229
___
___
Python-bugs-list
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Jan 11, 2011 at 11:20 AM, Tomas Kubes rep...@bugs.python.org wrote:
..
You should try to think like a person that does not have any background
knowledge of underlying libraries but
just looks through the time
Tomas Kubes mr_na...@centrum.cz added the comment:
I think you are confusing the purposes of a reference manual with that
of a tutorial or an FAQ collection.
There is a fine line between them. Even though reference manual should not be a
substitute for a tutorial, I still believe it should
Georg Brandl ge...@python.org added the comment:
It seems to me that the quoted function from bzr
def local_time_offset(t=None):
Return offset of local zone from GMT, either at present or at time t.
# python2.3 localtime() can't take None
if t is None:
t = time.time()
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Jan 11, 2011 at 1:56 PM, Georg Brandl rep...@bugs.python.org wrote:
..
It seems to me that the quoted function from bzr ...
would be very helpful to add to the `time` module docs as an example.
The problem with
anatoly techtonik techto...@gmail.com added the comment:
On Tue, Jan 11, 2011 at 4:52 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
..
http://docs.python.org/library/time.html#time.daylight
- Nonzero if a DST timezone is defined.
+ .. To check if DST is currently active, use
anatoly techtonik techto...@gmail.com added the comment:
On Tue, Jan 11, 2011 at 9:42 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
I have to agree with the OP that the current state of the docs is not as
clear as it could be.
In some ways the state of the docs is reflective of the
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Jan 11, 2011 at 4:15 PM, anatoly techtonik
rep...@bugs.python.org wrote:
..
To summarize: What is wrong with my previous proposal if we remove t
from params?
Not much is wrong with it. If it would come in a
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am going to reject this. None of the proposed changes seem to be better than
the current documentation. The time.daylight variable has the same meaning as
eponymous C variable defined in time.h header. The latter is
Georg Brandl ge...@python.org added the comment:
Please do!
--
assignee: georg.brandl - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7229
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
After reading the new wording on a formatted page, I don't like the proposed
changes:
time.altzone
When daylight is nonzero, altzone specifies the offset of the local DST
timezone, in seconds west of UTC. This is
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Georg,
Do you mind if I take this over?
While I have issues with east/west of UTC terminology, it is the accepted
terminology throughout the manual and Brian's rewording is an improvement.
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
It may be a bit off-topic for this issue, but I don't like that the python
manual uses UTC as if it was a geographical location. UTC is a time scale.
You cannot be to the east or to the west of UTC just as you cannot be
anatoly techtonik techto...@gmail.com added the comment:
It is too hard to track this issue without quotes from manual. Let's bring
context into discussion:
http://docs.python.org/library/time.html#time.altzone
UTC offset of the local DST timezone if one is defined. Only use this if
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
rep...@bugs.python.org wrote:
..
As for offtopic UTC vs GMT - I doubt there is a way to clearly express that
the offset sign of the
returned values is negated in
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
rep...@bugs.python.org wrote:
..
So, to answer a question What is the current UTC offset? you need to:
if time.daylight:
if time.altzone: # using only if defined
New submission from Tomas Kubes mr_na...@centrum.cz:
Hello,
it is not obvious that the time.daylight data item reports nonzero
values even when DST is currently not being used (ie. in winter) but the
active timezone has DST defined for some other parts of the year.
Current manual entry can be
25 matches
Mail list logo
