[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics

Alexander Belopolsky added the comment: Here is a shorter example of inconsistent behavior: >>> 0.5 * timedelta(microseconds=1) datetime.timedelta(0) >>> timedelta(microseconds=0.5) datetime.timedelta(0, 0, 1) -- ___ Pyt

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

Alexander Belopolsky added the comment: Does this need to be brought up on python-dev for acceptance? -- nosy: +mark.dickinson stage: unit test needed -> patch review versions: +Python 3.2 -Python 2.7 ___ Python tracker <http://bugs.pyth

[issue5023] Segfault in datetime.time.strftime("%z")

Changes by Alexander Belopolsky : -- stage: -> unit test needed ___ Python tracker <http://bugs.python.org/issue5023> ___ ___ Python-bugs-list mailing list Un

[issue5023] Segfault in datetime.time.strftime("%z")

Alexander Belopolsky added the comment: Philipp, Why do you think you see the same problem as Eric? Can you set a trace on &tuple and see when it gets modified? Do you see the crash with zone_failure.py, test_datetime.py or both? -- ___ Py

[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics

Alexander Belopolsky added the comment: Mark> (2) seems like overkill to me. I agree, however it would be interesting to figure out when accumulated errors can produce an inaccurate result. ISTM that leftover is the sum of up to 7 doubles each between 0 and 1 which is then rounded to

[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics

Alexander Belopolsky added the comment: I wonder if it would be justified to expose something like int _PyLong_IsOdd(PyObject *self) { PyLongObject *lo = (PyLongObject *)self; return Py_SIZE(lo) != 0 && ((lo->ob_digit[0] & 1) != 0); }

[issue1766304] improve xrange.__contains__

Alexander Belopolsky added the comment: On Wed, Jun 2, 2010 at 11:17 AM, Tal Einat wrote: .. > If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will > have time to review > (and possibly commit) in time for RC1 I guess I'll take my time with this. I'l

[issue1766304] improve xrange.__contains__

Changes by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker <http://bugs.python.org/issue1766304> ___ ___ Python-bugs-list mailing list Un

[issue1766304] improve xrange.__contains__

Alexander Belopolsky added the comment: This is already in 3.x. The only reason I can think of to get this in 2.7 is to have fewer performance surprises between 2.x and 3.x. -- ___ Python tracker <http://bugs.python.org/issue1766

[issue5434] datetime.monthdelta

Alexander Belopolsky added the comment: Rejecting this for stdlib. A 3rd party package is available at http://pypi.python.org/pypi?name=MonthDelta&:action=display . -- stage: -> committed/rejected status: pending -> closed ___ Pyth

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Here is my first attempt to implement fixed offset timezone type. The patch is based on Brett's next-patch.txt and while I changed the type name from datetime.UTC to datetime.timezone, I did not change the name of the related C structures. I

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Wed, Jun 2, 2010 at 5:24 PM, Brett Cannon wrote: .. > 1. Call it FixedTimezone or something (remember it has to be CapWords). I thought consistency within module trumps PEP 8 naming standards. The datetime module (for better or worse) uses lowerc

[issue2568] Seconds range in time unit

Alexander Belopolsky added the comment: I am reopening this issue because the following note is still not entirely correct: """ The range really is 0 to 61; according to the Posix standard this accounts for leap seconds and the (very rare) double leap seconds. The time modu

[issue6608] asctime causing python to crash

Alexander Belopolsky added the comment: Here is a quote from the relevant CERT advisory (MSC33-C): """ This function is supposed to output a character string of 26 positions at most, including the terminating zero. If we count the length indicated by the format directives

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am attaching the next installment of the datetime.timezone class implementation. Here I add ``utc`` class attribute to timezone. I decided to place it in class rather than module namespace because this seems to be more inline with how datetime

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson wrote: .. > Aren't there valid timezones that are offset by more than 12 hours from UTC? I am not sure. At this stage treat 12 as a placeholder for whatever the relevant standard says. I

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:41 PM, Alexander Belopolsky wrote: .. > I am not sure.   At this stage treat 12 as a placeholder for whatever > the relevant standard says. Believe it or not, at least one standard, RFC 2822, allows any offset representa

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:15 PM, Brett Cannon wrote: .. > As for the float/int argument, I personally am wary of it. Since the > timedelta constructor accepts hours as a keyword argument, I don't > see the benefit of having to support both

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker <http://bugs.python.org/issue5094> ___ ___ Python-bugs-list mailing list Un

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am having second thoughts about dst indicator. I wrote: """ 2. Do we want to add a dst indicator and altname attributes? I would say: no. I would rather treat DST as a different fixed offset timezone. """ and Brett res

[issue8810] TZ offset description is unclear in docs

Alexander Belopolsky added the comment: > In this case, the docs.python.org link you point to seems > to be correct, saying that it returns a timedelta. This issue is specifically about ReST documentation, not the docstring. I explained in the opening comment that 'It is later exp

[issue8810] TZ offset description is unclear in docs

Changes by Alexander Belopolsky : -- stage: committed/rejected -> needs patch ___ Python tracker <http://bugs.python.org/issue8810> ___ ___ Python-bugs-list mai

[issue8810] TZ offset description is unclear in docs

Changes by Alexander Belopolsky : -- resolution: accepted -> ___ Python tracker <http://bugs.python.org/issue8810> ___ ___ Python-bugs-list mailing list Un

[issue8810] TZ offset description is unclear in docs

Alexander Belopolsky added the comment: Sean, It looks like you committed your first patch rather than your second. Is that what you intended? Also in msg106734, you agree to change "West" to "west", but committed "West." Note that "west" is

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > So you want a third argument that lets you flag if the timezone is DST or not? The third argument is not a flag, it is a timedelta just like the offset. I am attaching a python prototype for clarity. (See datetimeex.py.) Conceptually, a 3-argum

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson wrote: .. > Aren't there valid timezones that are offset by more than 12 hours from UTC? Indeed, Christmas Island uses UTC+14. (http://en.wikipedia.org/wiki/Kiritimati). The most western timezone

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Merging in issue7584 nosy list. -- nosy: +durban, l0nwlf, r.david.murray, techtonik ___ Python tracker <http://bugs.python.org/issue5

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: > It seems to me that we should not try to produce an RFC 3339 compliant > date string from a naive datetime. It will be practical to accept > that restriction once issue 5094 is resolved. Does this mean that t.rfcformat() should fail if t

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > I'm still leary of supporting any form of DST. A proper DST > implementation would need to have some conditional code to > account for the datetime object passed into dst, and yet the > version you have prototyped doesn't hand

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Alexander Belopolsky : -- nosy: +tim_one ___ Python tracker <http://bugs.python.org/issue5094> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1647654] No obvious and correct way to get the time zone offset

Alexander Belopolsky added the comment: Issue #1667546 is more ambitious than this. I propose a very simple patch which makes tm_zone and tm_gmtoff available on systems with HAVE_STRUCT_TM_TM_ZONE defined (Linux and BSD variants). The additional fields are only allowed as attributes so len

[issue1647654] No obvious and correct way to get the time zone offset

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file17555/issue1647654a.diff ___ Python tracker <http://bugs.python.org/issue1647654> ___ ___ Pytho

[issue8899] Add docstrings to time.struct_time

New submission from Alexander Belopolsky : The time.struct_time class is missing class and field docstrings: >>> time.struct_time.__doc__ is None True >>> time.struct_time.tm_year.__doc__ is None True This is significant because it is not obvious that field values are differ

[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics

Alexander Belopolsky added the comment: The timedelta(seconds=0.6112295) example is handled correctly because 0.6112295 sec is not half way between two nearest microseconds: >>> abs(0.6112295 - 0.6112290) == abs(0.6112295 - 0.6112300) False The fact that it displays as if it is does

[issue8860] Rounding in timedelta constructor is inconsistent with that in timedelta arithmetics

Alexander Belopolsky added the comment: The half-way check should be done with decimal arihmetics, but the result is the same: >>> x = Decimal(0.6112295) >>> abs(x - Decimal('0.6112290')) == abs(x - Decimal('0.6112300')) False --

[issue8899] Add docstrings to time.struct_time

Alexander Belopolsky added the comment: Please see fixes in issue8899.diff. * Quite a few lines are pretty long. Please stay below 80 chars/line. Fixed. * There are trailing spaces in two member docs. Fixed. * The range notation is inconsistent. [first, last] or [first, last+1) is what

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon wrote: .. > For the allowable range, follow the datetime docs as someone might be relying > on that specification already. > Will do. I think it is as simple simple s/12/24/ in two places of th

[issue8899] Add docstrings to time.struct_time

Changes by Alexander Belopolsky : -- resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue8899> ___ ___ Python-bugs-list mailing list Un

[issue8899] Add docstrings to time.struct_time

Alexander Belopolsky added the comment: Committed in r81756 (trunk) and r81757 (py3k). -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue8907] time module documentation differs in trunk and py3k

New submission from Alexander Belopolsky : Doc/library/time.rst differs in trunk and py3k. It appears that the trunk version is more up to date and can simply replace the py3k version, but I would like to have another pair of eyes to take a look before committing. I also noticed that

[issue8907] time module documentation differs in trunk and py3k

Changes by Alexander Belopolsky : -- nosy: +d...@python ___ Python tracker <http://bugs.python.org/issue8907> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik wrote: .. > s/datetime/date\/time/ in the last sentence, as the complication comes  from: > -- start offtopic -- > 1. the vast amount of various date and time modules/functions "Vas

[issue7229] Manual entry for time.daylight can be misleading

Alexander Belopolsky 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 to the north of the Greg

[issue7582] [patch] diff.py to use iso timestamp

Alexander Belopolsky added the comment: The latest patch will produce wrong results if the file was last modified before timezone rules changed in your location. See issue1647654. -- assignee: -> belopolsky dependencies: +No obvious and correct way to get the time zone off

[issue7229] Manual entry for time.daylight can be misleading

Alexander Belopolsky added the comment: On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik 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 comparison with real "UTC offsets" with

[issue7229] Manual entry for time.daylight can be misleading

Alexander Belopolsky added the comment: On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik 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 >     use time.altzone >  else

[issue8903] datetime functions

Alexander Belopolsky added the comment: How hard is it to add now = datetime.now todate = date.today at the top of your module is you really like shorter names? -1 -- assignee: -> belopolsky nosy: +belopolsky priority: normal -> low ___

[issue8902] add datetime.time.now() for consistency

Alexander Belopolsky added the comment: Anatoly, Didn't you just recently complain about the large number of functions in datetime module? (issue7584) datetime.datetime.now().time() seems adequate to me. What is your use case? -- assignee: -> belopolsky nosy: +belopolsky

[issue1777412] Python's strftime dislikes years before 1900

Alexander Belopolsky added the comment: I see this in py3k branch on MacOS X: [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> date

[issue3173] external strftime for Python?

Alexander Belopolsky added the comment: What platforms have broken strftime and how badly is it broken there? Is there a python version somewhere? PyPy? -- assignee: -> belopolsky nosy: +belopolsky type: -> feature request ___ Python t

[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

Alexander Belopolsky added the comment: With recent enhancements to datetime module, timegm has become a 1-liner: EPOCH = 1970 _EPOCH_DATETIME = datetime.datetime(EPOCH, 1, 1) _SECOND = datetime.timedelta(seconds=1) def timegm(tuple): """Unrelated but handy function to

[issue1083] Confusing error message when dividing timedelta using /

Alexander Belopolsky added the comment: Closing as duplicate of issue1289118. Division of timedelta by integer is supported in py3k since r81625. -- nosy: +belopolsky -Alexander.Belopolsky resolution: -> duplicate status: open -> closed superseder: -> timedelta multiply a

[issue7463] PyDateTime_IMPORT() causes compiler warnings

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky stage: -> needs patch ___ Python tracker <http://bugs.python.org/

[issue7989] Transition time/datetime C modules to Python

Alexander Belopolsky added the comment: As far as I remember, the datetime module started as a pure python module and was reimplemented in C around year 2003 or so. One of the important additions at that time was the C API to datetime functionality. I am afraid that with the _timemodule.c

[issue1726687] Bug found in datetime for Epoch time = -1

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker <http://bugs.python.org/issue1

[issue7662] time.utcoffset()

Alexander Belopolsky added the comment: I would prefer exposing tm_gmtoff in time.localtime() output. The advantage is that on platforms that support it is struct tm, it will return correct offset for times in the past, not only for the current time. See issue1647654. On platforms without

[issue5979] strptime() gives inconsistent exceptions

Alexander Belopolsky added the comment: Looks like a bug to me: >>> datetime.strptime("1", "%d") datetime.datetime(1900, 1, 1, 0, 0) >>> datetime.strptime('1', '%m') datetime.datetime(1900, 1, 1, 0, 0) both %m and %d accept single dig

[issue5979] strptime() gives inconsistent exceptions

Changes by Alexander Belopolsky : -- versions: +Python 3.2 -Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5

[issue1982] Feature: extend strftime to accept milliseconds

Alexander Belopolsky added the comment: With %f support in, isn't this issue out of date? -- assignee: -> belopolsky nosy: +belopolsky stage: -> unit test needed versions: +Python 3.2 -Python 2.6 ___ Python tracker <http://b

[issue2516] Instance methods are misreporting the number of arguments

Changes by Alexander Belopolsky : Removed file: http://bugs.python.org/file14759/unnamed ___ Python tracker <http://bugs.python.org/issue2516> ___ ___ Python-bugs-list m

[issue2516] Instance methods are misreporting the number of arguments

Alexander Belopolsky added the comment: gungor: your messages look mangled. It may be the case of email to trucker bug. Can you briefly explain what you are trying to add to the discussion? -- assignee: -> belopolsky ___ Python tracker &l

[issue8913] Document that datetime.__format__ is datetime.strftime

Alexander Belopolsky added the comment: I wonder if this is subject to change. I find it odd that >>> "{:g}".format(1e3) '1000' but one has to use % in >>> "{:%Y}".format(datetime.now()) '2010' It is also different from PEP 3101

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am attaching the next version of my patch and changing priority to high because it appears that several issues depend on resolution of this one. Here is the summary of changes since issue5094a.diff: 1. The constructor now accepts only whole number of

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Good catch, Daniel! Fixed in issue5094c.diff. -- Added file: http://bugs.python.org/file17570/issue5094c.diff ___ Python tracker <http://bugs.python.org/issue5

[issue7463] PyDateTime_IMPORT() causes compiler warnings

Alexander Belopolsky added the comment: PyCObject is deprecated in 2.7 and removed in 3.x. PyCapsule_Import() should be used instead of PyCObject_Import() and it already has correct signature: Include/pycapsule.h:PyAPI_FUNC(void *) PyCapsule_Import(const char *name, int no_block); Since

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: I have updated time-4.diff patch for py3k. Code changes are minimal, mostly due to string to unicode conversion. I have not attempted to fix anything beyond passing supplied unittest, but I did noticed a few missing error return tests. I was not able

[issue8913] Document that datetime.__format__ is datetime.strftime

Alexander Belopolsky added the comment: The problem I have with strftime %-format codes is that according to BSD manual page they have already ran out of English alphabet and still "there is no conversion specification for the phase of the moon." :-) On a serious note, there are n

[issue7989] Transition time/datetime C modules to Python

Alexander Belopolsky added the comment: For the datetime module there are also a few more subtle issues that would make it difficult to make a hybrid C/Python implementation. The problem is that unlike the time module where most of the functionality is implemented in module level functions

[issue7989] Transition time/datetime C modules to Python

Changes by Alexander Belopolsky : -- versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue7989> ___ ___ Python-bugs-list mailing list Unsub

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Readying the patch for commit. Added documentation, tests and implementation of fromutc() method that does not need a dst(). -- resolution: -> accepted Added file: http://bugs.python.org/file17585/issue5094d.d

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Thanks, Daniel. This was a leftover from the previous patch. The latest patch does not actually change utcnow(). Instead the users should call datetime.now(timezone.utc). Fixed in issue5094d1.diff. -- Added file: http://bugs.python.org

[issue7989] Transition time/datetime C modules to Python

Alexander Belopolsky added the comment: Brett Cannon wrote in a comment (msg106498) on another issue: """ The stated long-term goal of the stdlib is to minimize the C extension modules to only those that have to be written in C (modules can still have performance enhancing

[issue7989] Transition time/datetime C modules to Python

Alexander Belopolsky added the comment: Also, my opposition is only to splitting datetime. While I am not against splitting the time module, I believe it should be phased out eventually and posix compatibility portion folded into posix module

[issue7989] Transition time/datetime C modules to Python

Alexander Belopolsky added the comment: Brett, Thanks for your explanation. It looks like I misunderstood the proposal. I though the idea was to have some methods of e.g. date type implemented in python and some in C. What you propose is much simpler. Effectively, your proposal is

[issue7989] Add pure Python implementation of datetime module to CPython

Alexander Belopolsky added the comment: I am changing the title to match Brett's explanation better. Note that since the time module is a thin wrapper around C library calls, it falls under inherently relying on C code exception. -- title: Transition time/datetime C modul

[issue6641] strptime doesn't support %z format ?

Changes by Alexander Belopolsky : -- dependencies: +datetime lacks concrete tzinfo impl. for UTC stage: -> unit test needed type: behavior -> feature request versions: +Python 3.2 -Python 2.6 ___ Python tracker <http://bugs.python.org/

[issue6641] strptime doesn't support %z format ?

Alexander Belopolsky added the comment: Attached patch includes issue 5094 patch. -- keywords: +patch nosy: +mark.dickinson stage: unit test needed -> commit review Added file: http://bugs.python.org/file17590/issue6641.diff ___ Python trac

[issue2651] Strings passed to KeyError do not round trip

Alexander Belopolsky added the comment: KeyError.patch is out of date. Is anyone motivated enough to update it for py3k? I like the idea, but don't have spare cycles at the moment. -- ___ Python tracker <http://bugs.python.org/i

[issue8902] add datetime.time.now() for consistency

Alexander Belopolsky added the comment: Anatoly, msg107191 belongs to issue8903, not here and it is not a use case, but rather a demonstration of how the proposed feature would work. My question is why would an application need current time without current date? I feel providing time.now

[issue8903] Add module level now() and today() functions to datetime module

Alexander Belopolsky added the comment: Note that it is important to keep class methods because in some cases it is convenient to obtain now/today from datetime/date instances instead of importing them from the module. So deprecating class methods is not an option and adding module level

[issue8907] time module documentation differs in trunk and py3k

Alexander Belopolsky added the comment: There seems to be a few legitimate differences such as "int or long" vs. integer, or parenthesis for print. Patch is forthcoming. -- ___ Python tracker <http://bugs.python.

[issue8907] time module documentation differs in trunk and py3k

Alexander Belopolsky added the comment: .. also 3.x does not track versionadded from 2.x -- ___ Python tracker <http://bugs.python.org/issue8907> ___ ___ Pytho

[issue614557] LookupError etc. need API to get the key

Alexander Belopolsky added the comment: It looks like issue2651 is the first step for this. See msg66432. I am merging the nosy lists. -- assignee: -> belopolsky dependencies: +Strings passed to KeyError do not round trip nosy: +amaury.forgeotdarc, belopolsky, pitrou, rharris st

[issue836035] strftime month name is encoded somehow

Alexander Belopolsky added the comment: Is this still an issue in 3.x? With time.strftime() returning unicode, I don't think any encoding issues remain. -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs

[issue887237] Machine integers

Changes by Alexander Belopolsky : -- assignee: -> belopolsky components: +Extension Modules, ctypes -Library (Lib) nosy: -Alexander.Belopolsky stage: -> patch review versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/is

[issue8947] Provide as_integer_ratio() method to Decimal

New submission from Alexander Belopolsky : Here is my use case: recently implemented timedelta * float operation starts with converting float to an int ratio. The same algorithm can be used for decimals, but they don't support as_integer_ratio(). -- components: Extension Mo

[issue8907] time module documentation differs in trunk and py3k

Alexander Belopolsky added the comment: Merged r81489 to py3k (r81840), but this affects datetime module docs, not time. On a closer examination, the differences in time.rst are correct. -- resolution: -> invalid status: open -> closed ___

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

Alexander Belopolsky added the comment: I have updated Amaury's patch for py3k. I simplified the test for default date values and fixed a documentation nit. (Time fileds are [4:7], not [4:6]). The result is attached as issue1100942.diff. Note that date.strptime accepts some time spec

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: I would like to take another shot at this. The link in Amaury's closing comment no longer works, so here is the relevant post: """ Returning same type as self for arithmetic in subclasses Tim Peters tim.peters at gmail.com Sat Jan

[issue1578643] various datetime methods fail in restricted mode

Alexander Belopolsky added the comment: I would like to remove datetime module dependency on time module altogether. For example getting timestamp as a float and later break it into sec/usec just to satisfy time module API looks rather inefficient. -- assignee: -> belopolsky n

[issue8957] strptime('%c', ..) fails to parse output of strftime('%c', ..) in non-English locale

New submission from Alexander Belopolsky : The following code: import locale, time locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8") t = time.localtime() s = time.strftime('%c', t) time.strptime('%c', s) Raises ValueError: time data '%c' does not match f

[issue8957] strptime('%c', ..) fails to parse output of strftime('%c', ..) in non-English locale

Changes by Alexander Belopolsky : Added file: http://bugs.python.org/file17602/strptime-locale-bug.py ___ Python tracker <http://bugs.python.org/issue8957> ___ ___ Pytho

[issue7739] time.strftime may hung while trying to open /etc/localtime but does not release GIL

Alexander Belopolsky added the comment: Victor, I understand your last comment as wanting to keep the GIL while calling tzset(), but release it around the strftime() call. You still want to apply your patch, right? I think the problem is not with a concurrent tzset() call, but with another

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: > If you want to challenge Guido's design decision, I think > python-dev would be the place to do it. Do you have a link supporting that it was "Guido's design decision"? This decision must have been made around class/typ

[issue2267] datetime.datetime operator methods are not subclass-friendly

Alexander Belopolsky added the comment: I also believe something needs to be fixed here in any case. Either Date.fromordinal(..) should return date or Date(..) + timedelta(..) should return Date. -- ___ Python tracker <http://bugs.python.

[issue1738] filecmp.dircmp does exact match only

Alexander Belopolsky added the comment: The patch does not apply to py3k branch. -- assignee: -> belopolsky stage: -> needs patch ___ Python tracker <http://bugs.python.org/

[issue665194] datetime-RFC2822 roundtripping

Alexander Belopolsky added the comment: -1 on adding more formatting/parsing methods to datetime. +1 on adding functions to email.utils that work with datetime objects. Adding #5094 as a dependency because RFC 2822 requires timezone information for proper formatting. -- dependencies

[issue8915] Use locale.nl_langinfo in _strptime

Alexander Belopolsky added the comment: See also issue8957. If this happens, I would like to add a pure python implementation strftime. See also issue7989. -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker <http://bugs.pyth

[issue8965] test_imp fails on OSX when LANG is set

New submission from Alexander Belopolsky : $ LANG=C ./python.exe -m test.regrtest test_imp test_imp test test_imp failed -- Traceback (most recent call last): File "Lib/test/test_imp.py", line 109, in test_issue5604 self.assertEqual(fs_encoding, 'utf-8') AssertionErro

[issue8963] test_urllibnet failure

Alexander Belopolsky added the comment: BTW, looking at test_bad_address(), I wonder why it puts extra dots in the url? The comment above it suggests that the intent is to use a name within RFC 2606 .invalid TLD. Not likely to be a problem in your case, but using made up TLD is not a good

<    23   24   25   26   27   28   29   30   31   32   >