Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22906>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I don't like the proposed note.
1. It is not the job of the time module documentation to warn about "many
functions in the stdlib." What are these functions, BTW?
2. What is "calendar time in POSIX encoding"? This sound
Alexander Belopolsky added the comment:
In the context of Python library documentation, the word "encoding" strongly
suggests that you are dealing with string/bytes. The situation may be
different in C. If you want to refer to something that is defined by the POSIX
standard you
Alexander Belopolsky added the comment:
> It is possible to inspect all stdlib functions that use time module and
> determine for some of them whether they will break if gmtime(0) is not
> 1970 or "right" zoneinfo is used or any non-POSIX time encoding is
> used. But it is
Alexander Belopolsky added the comment:
> I've provide the direct quote from *C* standard ...
I understand that C standard uses the word "encoding", but it does so for a
reason that is completely unrelated to the choice of epoch. "Encoding" is how
the bytes in mem
Alexander Belopolsky added the comment:
santhosh,
I would be interested to know how this gets resolved. I find it strange that
zon gets fractional UTC offset:
>>> zon
If you ask on a pytz-related forum, please post a link here.
Some other cases:
>>> pytz.ti
Alexander Belopolsky added the comment:
It looks like pytz documentation [1] specifically warns about this kind of
usage:
"""
Unfortunately using the tzinfo argument of the standard datetime constructors
‘’does not work’’ with pytz for many timezones.
"""
[
Alexander Belopolsky added the comment:
v3 looks good to me. BTW, I knew that the sign of TZ was significant, but
would have to look up the RFC to recall what the significance was. Thanks,
David, for the explanation.
--
___
Python tracker
Alexander Belopolsky added the comment:
See also discussion in #9079, #14127 and #14180. At some point there was some
resistance to use capsule mechanism to share code within stdlib and the
functions that were shared between time and datetime modules were moved to the
core.
I am -1 on
Alexander Belopolsky added the comment:
> .. the intent is not for better sleep support, but simply
> to be able to create and record time data which contains nano-seconds.
Can you describe a specific use-case? What's the advantage of the proposed
time.struct_timespec over say
&
Alexander Belopolsky added the comment:
> time() could be used to produce them
How?
--
___
Python tracker
<http://bugs.python.org/issue23084>
___
___
Python-
Alexander Belopolsky added the comment:
> it would be possible for datetime.datetime.now()
> to avoid the float time.
C implementation of datetime.now() does not rely on float time, so this is only
an issue for the Python implementation.
Moreover, as long as datetime keeps its micro
Alexander Belopolsky added the comment:
Would anyone object if I rename this issue to "Expose C struct timespec in time
module"? The current title is way too broad.
--
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
title: nanosecond support -> Expose C struct timespec (nanosecond resolution)
in time module
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
I would say that rejection note for PEP 410 [1] and the implementation of
st_[amc]time_ns fields in os.stats() have established a de-facto standard for
representing nanosecond resolution timestamps in Python.
I think this proposal should be rejected
Alexander Belopolsky added the comment:
> If I am reading data from an external device that has nanosecond
> resolution, how would I create such a time stamp in Python right now?
seconds * 10**9 + nanoseconds (translated to C API if nec
Alexander Belopolsky added the comment:
> but that seems to loose the type information after doing arithmetics
Hear, hear. See #2267. If you find out why Python was designed this way - let
me know.
--
___
Python tracker
<http://bugs.pyth
Alexander Belopolsky added the comment:
> can we change back the title because in fact
Please don't. If you would like to discuss general ideas - the right forum
would be the "python-ideas" mailing list.
We have no shortage of issue numbers: once you have another specifi
Alexander Belopolsky added the comment:
"nanosecond support [in Python]" is a PEP-size topic. As Victor suggested, "If
you are motivated enough, you may update the PEP and write a new one." The
tracker does not provide a sufficiently large forum to discuss "nan
Changes by Alexander Belopolsky :
--
components: +Extension Modules -Library (Lib)
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
What's a New Year without fixing a calendar bug! :-)
Jim's logic looks right to me. The patch needs a test before it can be applied.
--
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
Closing as a duplicate of #23136.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> BUG in how _strptime() handles week 0
versions: +Python 2.7, Python 3.2, Python 3.3
Alexander Belopolsky added the comment:
In a comment for #23134, Serhiy suggested that this may not be a bug
(msg233215) because C strptime behavior for this case is undefined.
I disagree. On Mac OSX, strptime man page states:
"""
The %U and %W format specifiers accept a
Alexander Belopolsky added the comment:
See also #12006.
--
___
Python tracker
<http://bugs.python.org/issue23136>
___
___
Python-bugs-list mailing list
Unsub
Alexander Belopolsky added the comment:
> For any valid string, strptime followed by strftime should return
> the same string.
Not necessarily. String to datetime mapping implemented by strptime can be
many to one. For example,
>>> datetime.strptime("2014 366", &quo
Alexander Belopolsky added the comment:
I would prefer to accept "denormalized" "%Y %W %w" combinations. Note that
while Mac OSX and glibc versions of strptime produce different results, neither
implementation signals an error by returning NULL.
> In C the strptime
Alexander Belopolsky added the comment:
Also, given that "2015 0 0", "2015 0 1", and "2015 0 3", all currently work
with '%Y %W %w' format specification and produce dates in the year 2014, I
think raising an error in all those cases is more likely
Changes by Alexander Belopolsky :
--
nosy: +Erik.Cederstrand, aganders3
___
Python tracker
<http://bugs.python.org/issue23136>
___
___
Python-bugs-list mailin
Alexander Belopolsky added the comment:
Note that round-trip also fails in weeks 52-53. For example,
>>> datetime.strptime('2014 53 6', '%Y %W %w')
datetime.datetime(2015, 1, 10, 0, 0)
>>> datetime.strptime('2014 53 6', '%Y %W %w').strf
Alexander Belopolsky added the comment:
Maybe Dmitry can come up with the "skipif" logic that will test for up-to date
tzinfo and skip the test if it is not. Otherwise we can try to come up with a
test case which is sufficiently far i
Alexander Belopolsky added the comment:
Do I understand correctly that the request is to append '+00:00' to the result
of dt.isoformat() when dt is naive? If so, -1. Python's datetime module does
not dictate how naive datetime instances should be interpreted. UTC by defaul
Alexander Belopolsky added the comment:
> I highly recommend always specifying the timezone and would consider behaving
> otherwise as a bug.
I agree, and the datetime module lets you do that already:
>>> dt = datetime.now(timezone.utc)
>>> dt.isoformat()
'201
Alexander Belopolsky added the comment:
> When using utcnow() e.g. I would expect the result definitely being marked as
> UTC.
Don't use utcnow(). This is a leftover from the times when there was no
timezone support in datetime.
The documentation for utcnow [1] already points
Alexander Belopolsky added the comment:
What is your specific proposal?
As I explained, we cannot assume that naive timezone instances are in UTC
because while sometimes they are (as in datetime.utcnow()), more often they are
not (as in datetime.now()). So changing dt.isoformat() when dt is
Alexander Belopolsky added the comment:
s/timezone instances/datetime instances/
--
___
Python tracker
<http://bugs.python.org/issue23332>
___
___
Python-bug
Alexander Belopolsky added the comment:
Mirko,
You may want to review #9527. I don't think we left any stone unturned in this
area.
--
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
Why do you call it a bug? Specifying UTC as +00:00 is perfectly valid by ISO
8601 and some RFCs that are based on the ISO standard recommend against using
the Z code.
--
___
Python tracker
<h
Alexander Belopolsky added the comment:
> ISO 8601 can and should be understood such as the TZ-designator is required
> (I think we agreed on that).
No. There is no such requirement in ISO 8601 as far as I remember.
--
___
Python tracker
Alexander Belopolsky added the comment:
Isn't this a duplicate of #13466?
--
___
Python tracker
<http://bugs.python.org/issue22799>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue22799>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Please take a look at msg148208. I agree with MAL that time module globals
timezone and daylight should be deprecated in favor of tm_gmtoff or
datetime.astimezone().
--
___
Python tracker
<h
Alexander Belopolsky added the comment:
This looks like a duplicate of #12750.
--
___
Python tracker
<http://bugs.python.org/issue23388>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue15795>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Alexander Belopolsky:
With the following simple setup.py
$ cat setup.py
from distutils.core import setup
from distutils.command.install import install
class install1(install):
sub_commands = install.sub_commamnds
setup(name='bug', cmdclass={'install&#
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file38064/setup1.py
___
Python tracker
<http://bugs.python.org/issue23426>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file38063/setup.py
___
Python tracker
<http://bugs.python.org/issue23426>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file38066/setup.py
___
Python tracker
<http://bugs.python.org/issue23426>
___
___
Python-bugs-list m
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file38063/setup.py
___
Python tracker
<http://bugs.python.org/issue23426>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
Attached patch fixes both issues.
--
___
Python tracker
<http://bugs.python.org/issue23426>
___
___
Python-bugs-list mailin
Changes by Alexander Belopolsky :
--
keywords: +patch
Added file: http://bugs.python.org/file38067/issue23426.patch
___
Python tracker
<http://bugs.python.org/issue23
Alexander Belopolsky added the comment:
Added tests.
--
stage: -> test needed
Added file: http://bugs.python.org/file38071/issue23426-with-tests.patch
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
--
stage: test needed -> commit review
___
Python tracker
<http://bugs.python.org/issue23426>
___
___
Python-bugs-list mai
Changes by Alexander Belopolsky :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
Actually, the real improvements came in changeset 67177:01714efdc6cf. Closing.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Pyhalov added the comment:
We have similar patch here in OpenIndiana. The patch is correct.
--
nosy: +Alexander.Pyhalov
___
Python tracker
<http://bugs.python.org/issue23
Alexander Pyhalov added the comment:
BTW, we use the following version for Python 3.4
--
Added file: http://bugs.python.org/file39539/socket.patch
___
Python tracker
<http://bugs.python.org/issue23
New submission from Bob Alexander:
Python session with 3.5b2
Showing existing error:
>>> from shutil import which
Works OK
>>> which("python")
'C:\\Python27\\python.EXE'
Also works OK
>>> which('C:\\Python27\\python.EXE')
'C:
Bob Alexander added the comment:
Hi R. David --
My report is just to notify y'all of a bug that I noticed. The bug is
causing me no problem, and it's your option as to whether to fix it or not.
I offered a fix, but I haven't the time to perform diffs, etc. You could
make tha
Alexander Belopolsky added the comment:
Victor> I don't know yet if it should be fixed or not.
It is my understanding that datetime -> timestamp -> datetime round-tripping
was exact in 3.3 for datetimes not too far in the future (as of 2015), but now
it breaks for datetime(2015,
Alexander Belopolsky added the comment:
I'll let others fight this battle. In my view, introducing floating point
timestamp method for datetime objects was a mistake. See issue #2736.
Specifically, I would like to invite Velko Ivanov to rethink his rant at
msg124197.
If anyone fol
Changes by Alexander Belopolsky :
--
nosy: -belopolsky
___
Python tracker
<http://bugs.python.org/issue23517>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Maybe it is time to rewrite trace module argument parser using argparse
and get an "always correct" auto-generated help for free?
--
keywords: +easy
stage: -> needs patch
versions: +Python 3.
Alexander Belopolsky added the comment:
Reverting to "needs patch" stage because there are still issues to be ironed
out.
--
stage: commit review -> needs patch
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.pytho
Alexander Belopolsky added the comment:
Please redirect this discussion to the recently opened datetime-sig mailing
list.
https://mail.python.org/pipermail/datetime-sig/
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Alexander Belopolsky:
Adds a boolean member to the instances of ``datetime.time``
and ``datetime.datetime`` classes that can be used to differentiate
between two moments in time for which local times are the same.
See Datetime-SIG "Local time disambiguation pro
Alexander Belopolsky added the comment:
Something went wrong in my hg clone and Rietveld did not like my patch. I
moved my development branch to github:
https://github.com/abalkin/cpython/tree/ltdf
Please feel free to leave your comments there
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file40096/ltdf-2.patch
___
Python tracker
<http://bugs.python.org/issue24773>
___
___
Python-bug
New submission from Alexander Oblovatniy:
Hi!
Current implementation of `patch.dict` spoils order of items in
`collections.OrderedDict`, because it explicitly converts passed `values` to
`dict`
(https://github.com/python/cpython/blob/923527f560acd43d4cc11293060900e56c7cb39b/Lib/unittest
Alexander Oblovatniy added the comment:
Hi!
Current implementation of `patch.dict` spoils order of items in
`collections.OrderedDict`, because it explicitly converts passed `values` to
`dict`
(https://github.com/python/cpython/blob/923527f560acd43d4cc11293060900e56c7cb39b/Lib/unittest
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
stage: -> needs patch
type: enhancement -> behavior
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40283/issue22241.diff
___
Python tracker
<http://bugs.python.org/issu
Changes by Alexander Belopolsky :
Added file: http://bugs.python.org/file40284/issue22241.diff
___
Python tracker
<http://bugs.python.org/issue22241>
___
___
Python-bug
Changes by Alexander Belopolsky :
Removed file: http://bugs.python.org/file40283/issue22241.diff
___
Python tracker
<http://bugs.python.org/issue22241>
___
___
Python-bug
Changes by Alexander Belopolsky :
--
title: datetime.utcfromtimestamp parses timestamps incorrectly ->
datetime.utcfromtimestamp rounds results incorrectly
___
Python tracker
<http://bugs.python.org/issu
Alexander Belopolsky added the comment:
I wish we could use the same algorithm in datetime.utcfromtimestamp as we use
in float to string conversion. This may allow the following chain of
conversions to round trip in most cases:
float literal -> float -> datetime -> seconds.mic
Alexander Belopolsky added the comment:
Since Russia has fixed this bug legislatively last year, can we close the issue
now?
http://www.theguardian.com/world/2014/jul/01/russia-state-duma-daylight-saving-time-summer
--
___
Python tracker
<h
Alexander Belopolsky added the comment:
C mktime itself should not change timezone globals, but it may indirectly if it
calls tzset() and TZ changed between calls.
I don't understand what this issue is about. Unlike C mktime, time.mktime is
not documented to call time.tzset(). If you
Changes by Alexander Belopolsky :
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
The premise of this issue is factually incorrect:
> ISO 8601, which states that, if no timezone is specified,
> the string is supposed to be interpreted as UTC implicitly.
The opposite is true: "If no UTC relation information is given
Alexander Belopolsky added the comment:
I probably misremembered a different issue. See msg194311.
>>> timedelta(seconds=0.6112295) == timedelta(seconds=1)*0.6112295
False
I thought the problem there was that the same float was converted to one
decimal by str() and to a different d
Alexander Belopolsky added the comment:
OK, I looked at the wrong place. Here is the correct example:
>>> x = float.fromhex('0x1.38f312b1b36bdp-1')
>>> x
0.6112295
>>> round(x, 6)
0.611229
>>> timedelta(0, x).microseconds
611230
but I no longer re
Alexander Belopolsky added the comment:
> You should have run the attached test_mktime_changes_tzname.c ...
I did run it and tried several times to understand what it does. It did not
help.
If you claim that calling mktime() changes the value of the global tzname
variable, you should
Changes by Alexander Belopolsky :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue22798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
> C tzname changes on my machine after the corresponding C mktime() calls
Did you run the code that I posted? If not - please do and report the results.
(I think there is a valid issue behind all this, but you are not helping to
reveal it. I susp
Alexander Belopolsky added the comment:
The timezone offset range restriction is not arbitrary. It was discussed in
issue 5094 (see msg107059 and responses to it.)
Nevertheless, there is an open proposal to remove all restrictions on offset
values and allow it to be an arbitrary timedelta
Alexander Belopolsky added the comment:
BTW, the specific issue that OP complains about is not a datetime issue:
apparently pytz has an even tighter restriction on timezone offsets.
I am going to close this as a third party issues, but those who support
relaxing datetime.timezone restriction
Changes by Alexander Belopolsky :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue22241>
___
___
Python-bugs-list mai
Alexander Belopolsky added the comment:
I always thought that restriction came from ISO 8601, but at the moment I don't
have it to check.
--
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
I'll try to find the time to kick the tires on this patch this weekend.
--
assignee: -> belopolsky
___
Python tracker
<http://bugs.python.org
Changes by Alexander Belopolsky :
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue23517>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
Victor,
Do I understand correctly that this is already committed in 3.4 - 3.6
development branches and we just need to decide whether to cherry-pick this fix
to 3.5rc?
Is the "review" link
Alexander Belopolsky added the comment:
It looks like this patch violates fromtimestamp(s) == EPOCH +
timedelta(seconds=s) invariant:
Python 3.6.0a0 (default:73911e6c97c8, Sep 4 2015, 13:14:12)
>>> E = datetime(1970,1,1,tzinfo=timezone.utc)
>>> s = -1/2**7
>>&g
Alexander Belopolsky added the comment:
Can someone check 3.3? I believe that was the release where we tried to get
various rounding issues right.
--
___
Python tracker
<http://bugs.python.org/issue23
Alexander Belopolsky added the comment:
Is there a CERT report associated with this vulnerability?
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Alexander Belopolsky :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
This is happening in windows-only code, so not being a windows user I cannot
reproduce it. It does not look like something new. This code was last touched
in #10653.
Can someone confirm that only 3.5 is affected?
--
nosy: +haypo
Alexander Belopolsky added the comment:
> Would you like us to report this and future vulnerabilities to CERT?
If it affects released versions, I think this is the right thing to do. Note
that I don't know what PSF policy is on this is or whether they even
Alexander Belopolsky added the comment:
This request is similar to (if not a duplicate of) issue 15873.
Gnu date uses the following extensions to %z instruction of strftime/strptime:
%z +hhmm numeric timezone (e.g., -0400)
%:z+hh:mm numeric timezone (e.g., -04:00
3601 - 3700 of 4097 matches
Mail list logo
