I think I've said all I can say in this thread; I'm sure you will come
up with a satisfactory solution.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
écrit :
I would be happy with just
if accept2dyear:
if 69 = y = 99:
y += 1900
elif 0 = y = 68:
y += 2000
# call system function with tm_year = y - 1900
Perfect. That's what I
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
If calling specific system functions such as strftime with tm_year
0 is deemed unsafe, we can move the check to where the system function
is called.
What do you mean by unsafe? Does it crash? On my Linux box,
strftime(%Y)
On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner
victor.stin...@haypocalc.com wrote:
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
If calling specific system functions such as strftime with tm_year
0 is deemed unsafe, we can move the check to where the system
Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :
On Thu, 06 Jan 2011 12:55:24 +0100, Victor Stinner
victor.stin...@haypocalc.com wrote:
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
If calling specific system functions such as strftime with tm_year
On 01/06/2011 11:08 AM, Victor Stinner wrote:
Le jeudi 06 janvier 2011 à 10:47 -0500, R. David Murray a écrit :
On Thu, 06 Jan 2011 12:55:24 +0100, Victor
Stinnervictor.stin...@haypocalc.com wrote:
Le jeudi 06 janvier 2011 à 00:10 -0500, Alexander Belopolsky a écrit :
If calling specific
On Thu, Jan 6, 2011 at 6:47 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Le mercredi 05 janvier 2011 à 23:48 -0500, Alexander Belopolsky a
écrit :
I would be happy with just
if accept2dyear:
if 69 = y = 99:
y += 1900
elif 0 = y = 68:
y +=
R. David Murray writes:
I believe that we have had several cases where Windows crashed when
out-of-range values were passed to the CRT that other platforms
accepted.
XEmacs had crashes due to strftime on Windows native with VC++. Never
went so far as to BSOD, but a couple of users lost
On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum gu...@python.org wrote:
Given the rule garbage in - garbage out, I'd do the most useful
thing, which would be to produce a longer output string (and update
the docs). This would match the behavior of e.g. '%04d' % y when y
. If that means
On Wed, 5 Jan 2011 12:33:55 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum gu...@python.org wrote:
Given the rule garbage in - garbage out, I'd do the most useful
thing, which would be to produce a longer output string (and
On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
Couldn't we deprecate and remove time.accept2dyear? It has been there
for backward compatibility since Python 1.5.2.
It will be useful for another 50 years or so. (POSIX 2-digit years
cover 1969 - 2068.) In any
On Wed, Jan 5, 2011 at 10:12 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 5, 2011 at 12:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
..
Couldn't we deprecate and remove time.accept2dyear? It has been there
for backward compatibility since Python 1.5.2.
It
On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum gu...@python.org wrote:
..
extending accepted range is a borderline case IMO.
I like accepting all years = 1 when accept2dyear is False.
Why = 1? Shouldn't it be = 1900 - maxint? Also, what is your take
on always accepting [1000 - 1899]?
On Wed, Jan 5, 2011 at 12:58 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 5, 2011 at 2:19 PM, Guido van Rossum gu...@python.org wrote:
..
extending accepted range is a borderline case IMO.
I like accepting all years = 1 when accept2dyear is False.
Why = 1?
On Jan 5, 2011, at 4:33 PM, Guido van Rossum wrote:
Shouldn't the logic be to take the current year into account? By the
time 2070 comes around, I'd expect 70 to refer to 2070, not to 1970.
In fact, I'd expect it to refer to 2070 long before 2070 comes around.
All of which makes me think
On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum gu...@python.org wrote:
..
Why = 1?
Because that's what the datetime module accepts.
What the datetime module accepts is irrelevant here. Note that
functions affected by accept2dyear are: time.mktime(), time.asctime(),
time.strftime() and
On Wed, Jan 5, 2011 at 2:55 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 5, 2011 at 4:33 PM, Guido van Rossum gu...@python.org wrote:
..
Why = 1?
Because that's what the datetime module accepts.
What the datetime module accepts is irrelevant here.
Not
On Wed, Jan 5, 2011 at 6:12 PM, Guido van Rossum gu...@python.org wrote:
..
If they both impose some arbitrary limits, it would be easier for
users to remember the limits if they were the same for both modules.
Unfortunately, that is not possible on 32-bit systems where range
supported by say
I'm sorry, but at this point I'm totally confused about what you're
asking or proposing. You keep referring to various implementation
details and behaviors. Maybe if you summarized how the latest
implementation (say python 3.2) works and what you propose to change
that would be quicker than this
On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum gu...@python.org wrote:
I'm sorry, but at this point I'm totally confused about what you're
asking or proposing. You keep referring to various implementation
details and behaviors. Maybe if you summarized how the latest
implementation (say
On Wed, Jan 5, 2011 at 6:46 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Jan 5, 2011 at 9:18 PM, Guido van Rossum gu...@python.org wrote:
I'm sorry, but at this point I'm totally confused about what you're
asking or proposing. You keep referring to various
On Wed, Jan 5, 2011 at 10:50 PM, Guido van Rossum gu...@python.org wrote:
..
I propose to change that to
if y 1000:
if accept2dyear:
if 69 = y = 99:
y += 1900
elif 0 = y = 68:
y += 2000
else:
raise ValueError(year out of range)
#
On Wed, Jan 5, 2011 at 10:50 PM, Guido van Rossum gu...@python.org wrote:
..
But what guarantees do we have that the system functions accept
negative values for tm_year on all relevant platforms?
Also note that the subject of this thread is limited to time.asctime
and time.ctime. The other
On Mon, Jan 3, 2011 at 7:47 PM, Guido van Rossum gu...@python.org wrote:
Given the rule garbage in - garbage out, I'd do the most useful
thing, which would be to produce a longer output string (and update
the docs).
I did not know that GIGO was a design rule, but after thinking about
it some
There are several reports of bugs caused by the fact that the behavior
of C functions asctime and ctime is undefined when they are asked to
format time for more than 4-digit years:
http://bugs.python.org/issue8013
http://bugs.python.org/issue6608 (closed)
http://bugs.python.org/issue10563
Given the rule garbage in - garbage out, I'd do the most useful
thing, which would be to produce a longer output string (and update
the docs). This would match the behavior of e.g. '%04d' % y when y
. If that means the platform libc asctime/ctime can't be used, too
bad.
--Guido
On Mon, Jan
26 matches
Mail list logo
