[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Alexander Belopolsky added the comment: Can we pick an API for this functionality that does not follow the worst of design anti-patterns? Constant arguments, varying return type, hidden import, and the list can go on. What is wrong with simply creating a new module, say "hirestime&

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Alexander Belopolsky added the comment: On Fri, Jan 27, 2012 at 5:17 PM, Antoine Pitrou wrote: > Well, creating a separate module is an anti-pattern in itself. calendar vs. > time vs. datetime, anyone? Are you serious? Since the invention of structural programming, creating a separate

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Changes by Alexander Belopolsky : -- nosy: +mark.dickinson ___ Python tracker <http://bugs.python.org/issue13882> ___ ___ Python-bugs-list mailing list Unsub

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Alexander Belopolsky added the comment: On Sun, Jan 29, 2012 at 6:42 PM, STINNER Victor wrote: .. > What do you call a constant argument? "float" and "decimal"? > You would prefer a constant like time.FLOAT_FORMAT? > Or maybe a boolean (decimal=True)? Yes. This wa

[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object

Alexander Belopolsky added the comment: On Mon, Jan 30, 2012 at 6:15 PM, STINNER Victor wrote: > Another possibility is what I proposed before in the issue #11457: take a > callback argument. > http://bugs.python.org/issue11457#msg143738 I think you are over-engineering a co

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Alexander Belopolsky added the comment: This is by design. I don't have a reference, but I do remember this being discussed. Suggestions for improving the documentation are welcome. -- ___ Python tracker <http://bugs.python.org/is

[issue14083] Use local timezone offset by default in datetime.timezone

Alexander Belopolsky added the comment: The problem with this idea is that while evaluating datetime.datetime.now(datetime.timezone()), python will have to query the real time clock twice (first in timezone() and then in now()). At a particularly unfortunate time this may result in an error

[issue14157] time.strptime without a year fails on Feb 29

Alexander Belopolsky added the comment: This strikes me as an implementation artifact. There is no reason for time.strptime() to validate date triplets. Applications that require valid dates can use datetime.strptime(). I suggest changing time.strptime() specification to match POSIX

[issue14262] Allow using decimals as arguments to `timedelta`

Alexander Belopolsky added the comment: I am -0 on the feature and -1 on the implementation. Conversion from Decimal to float is explicit by design. Decimal gives the user fine control over rounding issues allowing for either exact arithmetics (trapping inexact operation) or one of several

[issue14423] Getting the starting date of iso week from a week number and a year.

Alexander Belopolsky added the comment: Before you invest in a C version, let's discuss whether this feature is desirable. The proposed function implements a very simple and not very common calculation. Note that even dateutil does not provide direct support for this: you are instruct

[issue14423] Getting the starting date of iso week from a week number and a year.

Alexander Belopolsky added the comment: On Mon, Apr 9, 2012 at 6:20 PM, Marc-Andre Lemburg wrote: > Which is wrong, since the start of the first ISO week of a year > can in fact start in the preceeding year... Hmm, the dateutil documentation seems to imply that relativedelta takes c

[issue14423] Getting the starting date of iso week from a week number and a year.

Alexander Belopolsky added the comment: On Mon, Apr 9, 2012 at 6:56 PM, Antoine Pitrou wrote: > This is all a bit moot since we don't have a "relativedelta" in the > stdlib. It is still worthwhile to see how it is done elsewhere. So far, we have dateutil that does not h

[issue14423] Getting the starting date of iso week from a week number and a year.

Alexander Belopolsky added the comment: On Mon, Apr 9, 2012 at 7:28 PM, Marc-Andre Lemburg wrote: > You don't really expect anyone to remember such rules, do you ? :-) No, but it is still a one-line function that those who need it can easily implement. I am on the fence here be

[issue14423] Getting the starting date of iso week from a week number and a year.

Alexander Belopolsky added the comment: On Tue, Apr 10, 2012 at 6:44 AM, Antoine Pitrou wrote: > It's so easy that the patch isn't a one-liner and it seems to still have > bugs wrt. intended behaviour. Unless I miss something, the inverse to isocalendar() is simply from

[issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

Alexander Belopolsky added the comment: > I just ran the following script to check if there are any folds from > timestamps [0, 86399] in any timezone. Ammar, I am not sure pytz timezones support PEP 495 conventions. Can you repeat your experiment using the latest dateutil

[issue30302] Improve .__repr__ implementation for datetime.timedelta

Alexander Belopolsky added the comment: Sorry for being late to the discussion, but please allow me to add a -1 vote. The time.struct_time precedent is indeed comically verbose. Whenever I need to inspect a struct_time, I cast it to a plain tuple Compare >>> time.gmtime(1

[issue30302] Improve .__repr__ implementation for datetime.timedelta

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

[issue30822] Python implementation of datetime module is not being tested correctly.

Alexander Belopolsky added the comment: > Why is it so slow? The tests enabled by "-utzdata" check UTC to local and back conversions at several points around *every* time transition in *every* timezone. On systems with a complete installation of IANA tzdata, this is a lot o

[issue30516] Documentation for datetime substract operation incorrect?

Alexander Belopolsky added the comment: I agree. The documentation can be improved here. The note about x - y not being quite the same as x + (-y) belongs to the timedelta - timedelta operation. It should be removed from both date - timedelta and datetime-timedelta footnotes

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: This issue is waiting for the final decision on #5288. If sub-minute offsets support is accepted, I still don't think we need %::z because %:z can simply add non-zero :seconds as needed. There are also some review comments on the latest patch

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

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

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- priority: low -> versions: +Python 3.7 -Python 3.5 ___ Python tracker <http://bugs.python.org/issue5288> ___ ___ Python-

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- pull_requests: +2949 ___ Python tracker <http://bugs.python.org/issue5288> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: Most of the code supporting arbitrary offsets has already been committed. The only part left was to remove the checks and implement printing. -- ___ Python tracker <http://bugs.python.org/issue5

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

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

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: In PR 2896, I've modified %z formatting code to output sub-minute data if present. I think %z parsing should be also modified to accept sub-minute data, but I would like to do it in the context of issue 24954. Tho

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: John, An RFC3339 parser is beyond the scope of this issue which is limited to adding str[fp]time code(s) to produce and consume RFC3339-formatted timezones. We can still have fromisoformat() constructor implemented in 3.7, but someone needs to address

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: Victor, Tim called for removal of all restrictions on the offsets. See msg248468. I left the range restriction intact because we have some algorithms that rely on that, but in general I agree with Tim. There is nothing to be gained from restricting

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: > My concern is that it makes timestamp parsing more complex To the contrary. The timezone field can now be parsed the same way as the time field plus the sign. -- ___ Python tracker <http://bugs.pyth

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: New changeset 018d353c1c8c87767d2335cd884017c2ce12e045 by Alexander Belopolsky in branch 'master': Closes issue bpo-5288: Allow tzinfo objects with sub-minute offsets. (#2896) https://github.com/python/cpyt

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker <http://bugs.python.o

[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp

Alexander Belopolsky added the comment: The question is whether -62135658000.0 is the "correct" or even meaningful value: >>> datetime.utcfromtimestamp(-62135658000.0) Traceback (most recent call last): File "", line 1, in ValueError: year is out of range (I r

[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp

Alexander Belopolsky added the comment: On the second thought, a reasonable design can use datetime.min/max as placeholders for unknown times far in the past/future compensating for the lack datetime ±inf. In this use case, it may be annoying to see errors from timestamp() instead of some

[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp

Alexander Belopolsky added the comment: It your use case, the input "0001-01-01T00:00:00" was in what timezone? I suspect what you want is >>> datetime.min.replace(tzinfo=timezone.utc).timestamp() -62135596800.0 And not -62135658000.0. If you work with naive datetim

[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp

Alexander Belopolsky added the comment: BTW, I was originally against introducing .timestamp() method and this issue illustrates why it is problematic: people use it without understanding what it does. If you want the distance between datetime.min and datetime(1970,1,1) in seconds - compute

[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp

Alexander Belopolsky added the comment: > It still seems like this shouldn't give an error (especially when the > timezone of the local machine is UTC) This is the part where I agree with you. I suspect the error in the UTC case is an artifact of PEP 495 fold calculations t

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

Change by Alexander Belopolsky : -- pull_requests: +10105 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue9004> ___ ___ Py

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

Alexander Belopolsky added the comment: I submitted Gaurav's patch as PR 10870. Please review. -- ___ Python tracker <https://bugs.python.org/i

[issue35406] calendar.nextmonth and calendar.prevmonth functions doesn't check if the month is valid

Alexander Belopolsky added the comment: > On Dec 4, 2018, at 10:27 AM, Şahin wrote: > > Is there anything similar to this for "public API functions"? Yes - read the reference manual. If the function is not there it is not public. -- ___

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Change by Alexander Belopolsky : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> datetime.py implementation of .replace inconsistent with C implementation ___ Python tra

[issue17005] Add a topological sort algorithm

Alexander Belopolsky added the comment: Here is an implementation that I've used for years. It is somewhat shorter than the one in PR 11583: class CycleError(LogicalError, ValueError): """dependencies cycle detected """ def tsort(pairs): &quo

[issue32417] fromutc does not respect datetime subclasses

Alexander Belopolsky added the comment: New changeset 89427cd0feae25bbc8693abdccfa6a8c81a2689c by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-32417: Make timedelta arithmetic respect subclasses (#10902) https://github.com/python/cpyt

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Alexander Belopolsky added the comment: New changeset 89427cd0feae25bbc8693abdccfa6a8c81a2689c by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-32417: Make timedelta arithmetic respect subclasses (#10902) https://github.com/python/cpyt

[issue9051] Improve pickle format for timezone aware datetime instances

Changes by Alexander Belopolsky : -- resolution: -> rejected stage: patch review -> resolved status: pending -> closed ___ Python tracker <http://bugs.python.o

[issue28856] %b format for bytes does not support objects that follow the buffer protocol

Alexander Belopolsky added the comment: @xiang.zhang - I am the OP for this issue, so naturally I expect this to be fixed. I have a work-around in place for my own code, so I have no opinion on the particular versions. I guess the normal policy on bug fixes should apply

[issue29680] gdb/libpython.py does not work with gdb 7.2

Alexander Belopolsky added the comment: New changeset 661ca8843fed1183e38db06e52d59ac300bf1c2a by Lev Abalkin in branch 'master': Fixes bpo-29680: Older gdb does not have gdb.error. (#363) https://github.com/python/cpython/commit/661ca8843fed1183e38db06e52d59a

[issue29956] math.exp documentation is misleading

New submission from Alexander Belopolsky: The math.exp(x) function is documented to "Return e**x" <https://docs.python.org/3/library/math.html#math.exp>. This is misleading because even in the simplest case, math.exp(x) is not the same as math.e ** x: >>> import math

[issue29956] math.exp documentation is misleading

Alexander Belopolsky added the comment: > This is because math.e is not the same as e. Right. That's why I think it would be nice to distinguish math.e and the base of the natural logarithm typographically in the docs. Can we use sphinx math mode? If not, I would use italic

[issue28157] Document time module constants (timezone, tzname, etc.) as deprecated.

Alexander Belopolsky added the comment: The time and math modules are probably the oldest Python modules, but math have seen more development recently, so it should serve as a good model for how things should be organized. Yes, I believe re-listing module functions and constants in the

[issue28157] Document time module constants (timezone, tzname, etc.) as deprecated.

Alexander Belopolsky added the comment: A question for Victor: Should we split the "Constants" section into "Clock ID constants" and "Timezone constants"? (See PR 928.) -- ___ Python tracker <

[issue28157] Document time module constants (timezone, tzname, etc.) as deprecated.

Alexander Belopolsky added the comment: Cheryl, There is no need to apologize. I assigned this issue to myself when I created it because I had a few ideas about refactoring the time module documentation and thought I would get to it soon. As often happens other priorities interfered

[issue28157] Document time module constants (timezone, tzname, etc.) as deprecated.

Alexander Belopolsky added the comment: > The datetime module .. Yes, the datetime module documentation can be improved, but let's keep this issue focused on the time module. Please open a new issue for the datetime module impr

[issue28157] Document time module constants (timezone, tzname, etc.) as deprecated.

Changes by Alexander Belopolsky : -- keywords: -3.2regression ___ Python tracker <http://bugs.python.org/issue28157> ___ ___ Python-bugs-list mailing list Unsub

[issue29956] math.exp documentation is misleading

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue30443] datetime.datetime.__add__ does not respect fold.

Alexander Belopolsky added the comment: The current behavior is intentional. Please see PEP 495 for details. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.or

[issue36240] Definitions of time

Alexander Belopolsky added the comment: How about replacing "formerly known as Greenwich Mean Time, or GMT" with "which superseded Greenwich Mean Time or GMT as the basis of international timekeeping"? I don't think Python reference manual is the right place t

[issue9325] Add an option to pdb/trace/profile to run library module as a script

Change by Alexander Belopolsky : -- assignee: belopolsky -> ___ Python tracker <https://bugs.python.org/issue9325> ___ ___ Python-bugs-list mailing list Un

[issue32403] date, time and datetime alternate constructors should take fast construction path

Alexander Belopolsky added the comment: New changeset 9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-32403: Faster date and datetime constructors (#4993) https://github.com/python/cpython/commit/9f1b7b93f5f0ef589e7b272e127cac

[issue32404] fromtimestamp does not call __new__ in datetime subclasses

Alexander Belopolsky added the comment: New changeset 9f1b7b93f5f0ef589e7b272e127cacf4ce5d23f1 by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-32403: Faster date and datetime constructors (#4993) https://github.com/python/cpython/commit/9f1b7b93f5f0ef589e7b272e127cac

[issue32403] date, time and datetime alternate constructors should take fast construction path

Change by Alexander Belopolsky : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32403> ___ ___

[issue26647] ceval: use Wordcode, 16-bit bytecode

Change by Alexander Belopolsky : -- components: +Interpreter Core -Documentation stage: needs patch -> resolved ___ Python tracker <https://bugs.python.org/issu

[issue32625] Update the dis module documentation to reflect switch to wordcode

New submission from Alexander Belopolsky : A switch to wordcode is implemented in Python 3.6, but the documentation in the dis module was mostly left unchanged. See issue 26647, msg266388 and issue 27095, msg268389. -- assignee: docs@python components: Documentation messages: 310440

[issue32625] Update the dis module documentation to reflect switch to wordcode

Alexander Belopolsky added the comment: There is an uncommitted update for the EXTENDED_ARG opcode documentation attached to issue 27095 as mkfu4.patch by Demur Rumed. -- nosy: +Demur Rumed ___ Python tracker <https://bugs.python.org/issue32

[issue32625] Update the dis module documentation to reflect switch to wordcode

Change by Alexander Belopolsky : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue32625> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10381] Add timezone support to datetime C API

Alexander Belopolsky added the comment: New changeset 04af5b1ba9eb546a29735fac6cb5298159069b53 by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-10381: Add timezone to datetime C API (#5032) https://github.com/python/cpython/commit/04af5b1ba9eb546a29735fac6cb529

[issue10381] Add timezone support to datetime C API

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Alexander Belopolsky added the comment: New changeset 22864bc8e4a076bbac748ccda6c27f1ec41b53e7 by Alexander Belopolsky (Paul Ganssle) in branch 'master': Add What's new entry for datetime.fromisoformat (#5559) https://github.com/python/cpython/commit/22864bc8e4a076bbac748ccda

[issue32403] date, time and datetime alternate constructors should take fast construction path

Alexander Belopolsky added the comment: New changeset 5bd04f964b4f1bcdbd0fa36de04f087c2db07cfe by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-10381, bpo-32403: What's new entries for changes to datetime (gh-5814) https://github.com/python

[issue10381] Add timezone support to datetime C API

Alexander Belopolsky added the comment: New changeset 5bd04f964b4f1bcdbd0fa36de04f087c2db07cfe by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-10381, bpo-32403: What's new entries for changes to datetime (gh-5814) https://github.com/python

[issue32403] date, time and datetime alternate constructors should take fast construction path

Alexander Belopolsky added the comment: New changeset fff596f792a0752b0e571fa57809e5752aba6353 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': bpo-10381, bpo-32403: What's new entries for changes to datetime (gh-5814) (gh-5929) https://github.com/python

[issue10381] Add timezone support to datetime C API

Alexander Belopolsky added the comment: New changeset fff596f792a0752b0e571fa57809e5752aba6353 by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': bpo-10381, bpo-32403: What's new entries for changes to datetime (gh-5814) (gh-5929) https://github.com/python

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Alexander Belopolsky added the comment: New changeset 0e06be836ca0d578cf9fc0c68979eb682c00f89c by Alexander Belopolsky (Miss Islington (bot)) in branch '3.7': Add What's new entry for datetime.fromisoformat (GH-5559) (GH-5939) https://github.com/python

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Change by Alexander Belopolsky : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue8947] Provide as_integer_ratio() method to Decimal

Alexander Belopolsky added the comment: This issue has been superseded by #25928. -- resolution: rejected -> duplicate stage: patch review -> resolved superseder: -> Add Decimal.as_integer_ratio() ___ Python tracker <https://bug

[issue31327] bug in dateutil\tz\tz.py

Alexander Belopolsky added the comment: Is this similar to issue 29097? -- ___ Python tracker <https://bugs.python.org/issue31327> ___ ___ Python-bugs-list mailin

[issue28292] Make Calendar.itermonthdates() behave consistently in edge cases

Alexander Belopolsky added the comment: Let me look into this. It's been a while ... -- ___ Python tracker <https://bugs.python.org/issue28292> ___ ___

[issue28292] Make Calendar.itermonthdates() behave consistently in edge cases

Alexander Belopolsky added the comment: > 1. Raise OverflowError at both ends (revert issue15421patch). The method > becomes unusable for two extreme months. The issue 15421 patch was committed in 85710a40e7e9eab86060bedc3762ccf9ca

[issue28292] Make Calendar.itermonthdates() behave consistently in edge cases

Change by Alexander Belopolsky : -- keywords: +patch pull_requests: +4049 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue28292] Make Calendar.itermonthdates() behave consistently in edge cases

Alexander Belopolsky added the comment: I submitted PR 4079. Serhiy, please review the logic and if this matches what we discussed a year ago, I will add the docs and NEWS entries. -- ___ Python tracker <https://bugs.python.org/issue28

[issue31800] datetime.strptime: Support for parsing offsets with a colon

Alexander Belopolsky added the comment: Note that #5288 relaxed the whole number of minutes restriction on UTC offsets. Since the goal is to be able to parse the output of .isoformat(), I think %z should accept sub-minute offsets. -- nosy: +belopolsky

[issue28292] Make Calendar.itermonthdates() behave consistently in edge cases

Alexander Belopolsky added the comment: New changeset fdd9b217c60b454ac6a82f02c8b0b551caeac88b by Alexander Belopolsky in branch 'master': Closes bpo-28292: Implemented Calendar.itermonthdays3() and itermonthdays4(). (#4079) https://github.com/python/cpyt

[issue28281] Remove year limits from calendar

Change by Alexander Belopolsky : -- pull_requests: +4079 stage: commit review -> patch review ___ Python tracker <https://bugs.python.org/issue28281> ___ ___ Py

[issue28281] Remove year limits from calendar

Alexander Belopolsky added the comment: I submitted Mark's patch unchanged as PR 4109. If we don't hear from Mark, I will address my own comments and merge. -- ___ Python tracker <https://bugs.python.o

[issue31803] time.clock() should emit a DeprecationWarning

Alexander Belopolsky added the comment: I would like to add my voice to MAL's objections. I was not aware of time.clock() depreciation before Victor brought this issue to my attention. time.clock() is a very well-known API eponymous to a venerable UNIX system call. Its limitation

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: I am going to merge PR 4015 submitted for issue 31800. That issue asks to make %z strptime format accept offsets with : separators. Given that a similar feature has been added to glibc several years ago, I don't see much need for bikeshedding.

[issue31800] datetime.strptime: Support for parsing offsets with a colon

Alexander Belopolsky added the comment: New changeset 32318930da70ff03320ec50813b843e7db6fbc2e by Alexander Belopolsky (Mario Corchero) in branch 'master': Closes bpo-31800: Support for colon when parsing time offsets (#4015) https://github.com/python/cpyt

[issue28281] Remove year limits from calendar

Alexander Belopolsky added the comment: New changeset 66c88ce30ca2b23daa37038e1a3c0de98f241f50 by Alexander Belopolsky in branch 'master': Closes bpo-28281: Remove year (1-) limits on the weekday() function. (#4109) https://github.com/python/cpyt

[issue25729] update pure python datetime.timedelta creation

Alexander Belopolsky added the comment: Brian, is this still relevant? If so, cab you submit a pull request? -- versions: +Python 3.7 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue25

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I don't have access to NetBSD and this looks like a bug in the system implementation of localtime. The timestamp method is implemented by probing system localtime in the vicinity of UTC timestamp. What does time.localtime(14400) with these TZ set

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I hate this long form display! Next time please use time.localtime(14400)[:]. Do you agree that this is a system bug? On my Mac, I get $ python -c 'import time; print(time.localtime(14400)[:])' (1969, 12, 31, 23, 0, 0,

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I posted a wrong command, but fortunately I am in New York, so it did not matter $ TZ=EST+05EDT,M3.2.0,M11.1.0 python -c 'import time;print(time.localtime(14400)[:])' (1969, 12, 31, 23, 0, 0,

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I am not sure. This is a system bug and we often provide work-arounds or even reimplementations of buggy time functions in the time and datetime modules. Whether or not this is something that is worth fixing is a question for the affected NetBSD users

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: > The documentation only says “datetime.timestamp” calls “mktime” Indeed. See <https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp>. This is a documentation bug. Since 3.6 the timestamp does not call mktime. In fac

[issue32195] datetime.strftime with %Y no longer outputs leading zeros

Alexander Belopolsky added the comment: Isn't this a duplicate of issue 13305? -- status: pending -> open ___ Python tracker <https://bugs.python.org

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Alexander Belopolsky added the comment: The better is the enemy of the good here. Given the history of this issue, I would rather accept a well documented restrictive parser than wait for a more general code to be written. Note that we can always relax the parsing rules in the future

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Alexander Belopolsky added the comment: +1 on what Paul said. Mathieu, the goal for 3.7 will be to get Paul's PR merged. It will be great if you could help in reviewing it. We can return to the features in your PR during the 3.8 development

[issue32267] strptime misparses offsets with microsecond format

Change by Alexander Belopolsky : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue32267> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Alexander Belopolsky added the comment: New changeset 09dc2f508c8513e0466a759cc27a09108c1e55c2 by Alexander Belopolsky (Paul Ganssle) in branch 'master': bpo-15873: Implement [date][time].fromisoformat (#4699) https://github.com/python/cpython/commit/09dc2f508c8513e0466a759cc27a09

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: Maybe __round__ can be generalized to take a timedelta instead of ndigits? For some related prior art, take a look at <http://code.kx.com/q/ref/arith-integer/#xbar>. -- ___ Python tracker

[issue32522] Add precision argument to datetime.now

Alexander Belopolsky added the comment: In my experience, when dealing with temporal data truncation (rounding towards -infinity) is more useful than any other form of rounding. See also issue 19475. -- ___ Python tracker <https://bugs.python.

<    12   13   14   15   16   17   18   19   20   21   >