[issue32522] Add precision argument to datetime.now

leaks implementation details from `date.today()`, thus making it a slower, worse version of `datetime.now()`, since the overwhelmingly most common use cases for datetime rounding are probably "get today at midnight" and "get the current time with second precision". Still, I thin

[issue32522] Add precision argument to datetime.now

Barry A. Warsaw added the comment: The .replace(microseconds=0) hack annoys me too, but I'd be happier with a simpler solution: make datetime.now() accept a microseconds parameter, so datetime.now(microseconds=0) would be equivalent to datetime.now().replace(microseconds=0)

[issue32522] Add precision argument to datetime.now

Change by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue32522] Add precision argument to datetime.now

Change by Paul Ganssle : -- type: -> enhancement ___ Python tracker ___ ___

[issue32522] Add precision argument to datetime.now

Paul Ganssle added the comment: @Victor: With regards to getting a "date as datetime", that is another way to do it that I have also done in the past (and in fact it's how the new dateutil.utils.today() function is implemented:

[issue32522] Add precision argument to datetime.now

Paul Ganssle <p.gans...@gmail.com> added the comment: An alternate possibility here might be to implement either `__round__` or a `round` function in `datetime` (which would basically automatically add this precision functionality to *all* the constructors, not just now). An e

[issue32522] Add precision argument to datetime.now

STINNER Victor <victor.stin...@gmail.com> added the comment: > dt = datetime.now(precision='day') Why not creating a date and then convert it to a datetime object? > dt = datetime.now().replace(microseconds=0) Yeah, that one annoys me as well, but I learnt the .replace(microseco

[issue32522] Add precision argument to datetime.now

New submission from Paul Ganssle <p.gans...@gmail.com>: One thing I think that is fairly common is the desire to get the current datetime only up to a current precision, so you see a lot of things in, say, `dateutil` like this: dt = datetime.now().replace(hours=0, minutes=0, sec

[issue31950] Default event loop policy doc lacks precision

Antoine Pitrou added the comment: New changeset e65617f65e203a2a6d3e3100d0d6fed0ffa0613d by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-31950: Improve event loop policy doc (GH-4306) (#4307)

[issue31950] Default event loop policy doc lacks precision

Antoine Pitrou added the comment: Thank you Guido. This is fixed now. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31950] Default event loop policy doc lacks precision

Change by Roundup Robot : -- pull_requests: +4270 ___ Python tracker ___

[issue31950] Default event loop policy doc lacks precision

Antoine Pitrou added the comment: New changeset 4135c89395726024abddb7340a0c7a42c801f616 by Antoine Pitrou in branch 'master': bpo-31950: Improve event loop policy doc (#4306) https://github.com/python/cpython/commit/4135c89395726024abddb7340a0c7a42c801f616 --

[issue31950] Default event loop policy doc lacks precision

Change by Antoine Pitrou : -- keywords: +patch pull_requests: +4269 stage: -> patch review ___ Python tracker ___

[issue31950] Default event loop policy doc lacks precision

Guido van Rossum added the comment: Agreed that this needs more clarification. Is something stopping you from submitting a PR? Note that the thing about non-main-threads is mentioned in the docstring for BaseDefaultEventLoopPolicy. I agree that the best way to create a new

[issue31950] Default event loop policy doc lacks precision

python, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov priority: normal severity: normal status: open title: Default event loop policy doc lacks precision type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.o

Re: Precision reading and writing data frames to csv

the output with a field width > specifier or similar. If not, then you should see the initial change > you've noticed and then nothing more after that for that particular datum. Ok, I like that. > > > Having said all that, if you use Python's decimal.Decimal type instead > of floa

Re: Precision reading and writing data frames to csv

your files, then you are better off if absolute precision is what you need. E. -- https://mail.python.org/mailman/listinfo/python-list

Re: Precision reading and writing data frames to csv

On 2017-03-11 22:01, Paulo da Silva wrote: Hi! I have a dir with lots of csv files. These files are updated +- once a day. I could see that some values are converted, during output, to very close values but with lots of digits. I understand that is caused by the internal bits' representation of

Precision reading and writing data frames to csv

Hi! I have a dir with lots of csv files. These files are updated +- once a day. I could see that some values are converted, during output, to very close values but with lots of digits. I understand that is caused by the internal bits' representation of the float/double values. Now my question

[issue28744] Basic precision calc error

Zachary Ware added the comment: https://docs.python.org/3/tutorial/floatingpoint.html -- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue28744] Basic precision calc error

') -- components: Interpreter Core messages: 281191 nosy: Renner priority: normal severity: normal status: open title: Basic precision calc error type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

Re: What is precision of a number representation?

On Tue, Jul 12, 2016, at 02:21, Steven D'Aprano wrote: > If not, then what are the alternatives? Using str.format, how would > you get the same output as this? > > > py> "%8.4d" % 25 > '0025' "%04d" % 25 "%8s" % ("%04d" % 25) The latter (well, generally, "format it how you want and

Re: What is precision of a number representation?

On Tue, 12 Jul 2016 07:50 pm, Antoon Pardon wrote: > Op 12-07-16 om 06:19 schreef Steven D'Aprano: >> On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: >> >>> say, 2,147 >>> millimeters, with a precision of four significant digits >> >> How

Re: What is precision of a number representation?

Op 12-07-16 om 12:27 schreef Marko Rauhamaa: > Antoon Pardon <antoon.par...@rece.vub.ac.be>: > >> Op 12-07-16 om 06:19 schreef Steven D'Aprano: >>> How do you represent 1 mm to a precision of four significant digits, >>> in such a way that it is distinguished fr

Re: What is precision of a number representation?

Antoon Pardon <antoon.par...@rece.vub.ac.be>: > Op 12-07-16 om 06:19 schreef Steven D'Aprano: >> How do you represent 1 mm to a precision of four significant digits, >> in such a way that it is distinguished from 1 mm to one significant >> digit, and 1 mm to a preci

Re: What is precision of a number representation?

Op 12-07-16 om 06:19 schreef Steven D'Aprano: > On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: > >> say, 2,147 >> millimeters, with a precision of four significant digits > > How do you represent 1 mm to a precision of four significant digits, in such > a way that

Re: What is precision of a number representation?

On Tuesday 12 July 2016 08:17, Ethan Furman wrote: > So, so far there is no explanation of why leading zeroes make a number > more precise. Obviously it doesn't, just as trailing zeroes doesn't make a number more precise. Precision in the sense used by scientists is a property

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

On Tue, Jul 12, 2016 at 2:19 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: > >> say, 2,147 >> millimeters, with a precision of four significant digits > > > How do you represent 1 mm to a precision of four si

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

On Tue, 12 Jul 2016 07:51 am, Chris Angelico wrote: > say, 2,147 > millimeters, with a precision of four significant digits How do you represent 1 mm to a precision of four significant digits, in such a way that it is distinguished from 1 mm to one significant digit, and 1 mm to a pre

Re: What is precision of a number representation?

, with a precision of four significant digits, and excellent accuracy. But if I multiply those numbers together to establish the floor area of the corridor, the result does NOT have four significant figures. It would be 64 square meters (not 64.41), and the accuracy would be pretty low (effectively

Re: What is precision of a number representation?

On 7/11/2016 5:51 PM, Chris Angelico wrote: This is why it's important to be able to record precisions of arbitrary numbers. If I then measure the width of this corridor with a laser, I could get an extremely precise answer - say, 2,147 millimeters, with a precision of four significant digits

Re: What is precision of a number representation?

Ethan Furman <et...@stoneleaf.us> writes: > On 07/11/2016 01:56 PM, Ben Finney wrote: > > > Precision is not a property of the number. It is a property of the > > *representation* of that number. > > > > The representation “1×10²” has a precision of one dig

Re: What is precision of a number representation?

ay, 2,147 >> millimeters, with a precision of four significant digits, and >> excellent accuracy. But if I multiply those numbers together to >> establish the floor area of the corridor, the result does NOT have >> four significant figures. It would be 64 square meters (not

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

On Tue, Jul 12, 2016 at 9:14 AM, Jan Coombs wrote: > Thees all look good, but you may get into trouble if you trust a > PC with them! > > If the language/PC uses floating point representation then it > will assign a fixed number of bits for the fractional part,

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

On Tue, 12 Jul 2016 07:51:23 +1000 Chris Angelico <ros...@gmail.com> wrote: [snip] > > Yep. Precision is also a property of a measurement, the same > way that a unit is. If I pace out the length of the main > corridor in my house, I might come up with a result of thirty &g

Re: What is precision of a number representation?

Ben Finney <ben+pyt...@benfinney.id.au> writes: > Ethan Furman <et...@stoneleaf.us> writes: > >> I will readily admit to not having a maths degree, and so of course to >> me saying the integer 123 has a precision of 5, 10, or 99 digits seems >> like hogwash to

Re: What is precision of a number representation?

On 07/11/2016 03:17 PM, Ethan Furman wrote: So, so far there is no explanation of why leading zeroes make a number more precise. An example of what I mean: 174 with a precision of 3 tells us that the tenths place could be any of 0-9, or, put another way, the actual number could be anywhere

Re: What is precision of a number representation?

On 07/11/2016 02:51 PM, Chris Angelico wrote: On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney wrote: Precision is not a property of the number. It is a property of the *representation* of that number. The representation “1×10²” has a precision of one digit. The representation “100” has

Re: What is precision of a number representation? (was: Curious Omission In New-Style Formats)

On Tue, Jul 12, 2016 at 6:56 AM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Precision is not a property of the number. It is a property of the > *representation* of that number. > > The representation “1×10²” has a precision of one digit. > The representation “100” has

Re: What is precision of a number representation?

On 07/11/2016 01:56 PM, Ben Finney wrote: Precision is not a property of the number. It is a property of the *representation* of that number. The representation “1×10²” has a precision of one digit. The representation “100” has a precision of three digits. The representation “00100” has

What is precision of a number representation? (was: Curious Omission In New-Style Formats)

Ethan Furman <et...@stoneleaf.us> writes: > I will readily admit to not having a maths degree, and so of course to > me saying the integer 123 has a precision of 5, 10, or 99 digits seems > like hogwash to me. Precision is not a property of the number. It is a property of the

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Roundup Robot added the comment: New changeset eb120f50df4a by Alexander Belopolsky in branch 'default': Closes #19475: Added timespec to the datetime.isoformat() method. https://hg.python.org/cpython/rev/eb120f50df4a -- nosy: +python-dev resolution: -> fixed stage: commit review ->

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: Alessandro, thank you very much for your work and perseverance. I will do my best to commit this next weekend. -- stage: patch review -> commit review ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by SilentGhost : -- nosy: -SilentGhost ___ Python tracker ___ ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Meanwhile I made corrections after @belopolsky latest review -- Added file: http://bugs.python.org/file42063/issue19475_v17.patch ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

is higher than the precision you use to print it. .. For full seconds, truncation will add an error of +/- 1 second, whereas rounding only adds +/- 0.5 seconds. This is what convinced me to use rounding instead of truncation. """ I somehow missed this argument when Marc-Andre m

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

ser request: "Add timespec optional flag to datetime isoformat() to choose the precision". Let's wait until users request a datetime.round() method to understand better concrete issues. -- ___ Python tracker <rep...@bugs.python.org> <

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: Personally, I don't rounding is that useful. My working assumption is that users will select say timespec='millisecond' only when they know that their time source produces datetime instances with millisecond precision and they don't want to kill more

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

STINNER Victor added the comment: > Maybe a datetime.round() method along these lines will be a worthwhile > addition? Sorry, what is the use case of this method? -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: IIUC truncation traditionally means "towards zero" -- that's why we have separate "floor" and "ceiling" operations meaning "towards [negative] infinity". Fortunately we shouldn't have to deal with negative values here so floor and truncate mean the same

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: Except for the case where you're closer than half a usec from the next value, IMO rounding makes no sense when suppressing digits. I most definitely would never want 9:59:59 to be rounded to 10:00 when suppressing seconds. If you really think there are use

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

STINNER Victor added the comment: > But what should we do in your opinion? Use ROUND_FLOOR rounding method. time.time(), datetime.datetime.now(), etc. round the current time using the ROUND_FLOOR rounding method. Only datetime.datetime.fromtimestamp() uses ROUND_HALF_EVEN, but it's more an

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: I hope my prediction "I am afraid that the rounding issues may kill this proposal" (see msg202276) will not come true. I think the correct way to view "timespec" is a way to suppress/enforce printing of trailing digits. Users that choose printing less

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: But what should we do in your opinion? -- ___ Python tracker ___ ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

STINNER Victor added the comment: > Given that we're talking about what to do when we're suppressing the usecs I > don't think roundtripping matters. :-) I changed many times how Python rounds nanoseconds in the private PyTime API, and I got a bug report because of that! => issue #23517. By

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: Given that we're talking about what to do when we're suppressing the usecs I don't think roundtripping matters. :-) -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: Another argument for truncation is that this is what GNU date does: $ date --iso-8601=seconds --date="2016-03-01 15:00:00.999" 2016-03-01T15:00:00-0500 -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: Guido, Did you consider MAL's msg202274? I am still in favor of truncation, but would like to make sure we are not missing something that MAL knows from experience. -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by Alexander Belopolsky : -- stage: needs patch -> patch review ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: We discussed truncation vs. rounding some time ago. See msg202270 and the posts around it. The consensus was the same as Guido's current advise: do the truncation. -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: Out of context here, but regarding round vs. truncate, IIUC for time truncating down is the norm. My digital clock shows "12:00" for the duration of the minute starting at noon. People look for clocks to flip to know when it is exactly a given time (if the

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Oh, now I see your point. I've uploaded a new patch with a note for that. -- Added file: http://bugs.python.org/file42031/issue19475_v16.patch ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Martin Panter added the comment: About rounding: I’m not too sure what people would expect. Obviously it is much easier to implement truncating to zero. But it is different to many other rounding cases in Python; that is why I thought to make it explicit. >>>

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: New patch after @martin.panter comments on Rietveld. I left only this: - ``'milliseconds'``: Append the hours, minutes, seconds and milliseconds. > vadmium 2016/02/21 23:30:20 > I think this should explain that fractions are truncated to zero, never >

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by Andrei Dorian Duma : -- nosy: -andrei.duma ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Martin Panter added the comment: Left some review suggestions -- ___ Python tracker ___ ___ Python-bugs-list

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: New patch -- Added file: http://bugs.python.org/file41988/issue19475_v13.patch ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: I think Alexander has commit rights, he did most of the review, I trust him to commit it. -- ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: I left some comments on Rietveld. -- stage: commit review -> needs patch ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by Alexander Belopolsky : -- assignee: -> belopolsky stage: patch review -> commit review ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

SilentGhost added the comment: Yes, version 12 is the final patch. It doesn't add those options. To copy my opinion from the rietveld (https://bugs.python.org/review/19475/#msg14): > I don't really think nanoseconds belong here. If they don't > exist anywhere else in the module, why should

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: > I don't really think nanoseconds belong here. What about milliseconds? I'll leave it for Guido to make a call on nanoseconds. My vote is +0.5. > If they don't > exist anywhere else in the module, why should they be suddenly > introduced here? The

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: Is issue19475_v12.patch the final patch? I don't see it addressing Guido's suggestion in msg256470 to add milli- and nanoseconds options. -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Guido van Rossum added the comment: You can leave out the nanoseconds but please do add the milliseconds. I'm sure they would find more use than the option to show only the hours. -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

SilentGhost added the comment: > I there anything else I can do for this? I think you've done all you could, it's just someone needs to commit it. I don't think they're being rude on purpose - it's just that there are so many committers in the nosy list that no one is feeling like it's their

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: I there anything else I can do for this? -- ___ Python tracker ___ ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by R. David Murray : -- nosy: -r.david.murray ___ Python tracker ___ ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: up -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Martin Panter added the comment: I think there is a memory leak in the C code. I left some other minor suggestions as well, but it almost looks ready. -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Thanks @martin.panter, here is another patch made after your comments. -- Added file: http://bugs.python.org/file41464/issue19475_v12.patch ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by SilentGhost : -- stage: patch review -> commit review ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Berker Peksag added the comment: Thanks for the patch, Alessandro. I left some comments about documentation part of the patch, but I can fix them myself if you don't have time. -- stage: commit review -> patch review ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Berker, thank you. In the last patch, I removed details about timespec options in Python and C docstrings, corrected the rst quotes, and checked PEP7 in the c file. The only problem now is about versionchanged vs versionadded. I leave it as it was, as

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: what about the comment left by SilentGhost about versionadded? -- ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: > I think timespec= option should also be added to the time.isoformat method. @belopolsky I've done it in my last patch. -- Added file: http://bugs.python.org/file41420/issue19475_v10_datetime_time.patch ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker ___ ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Thanks SilentGhost! -- Added file: http://bugs.python.org/file41391/issue19475_v9.patch ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Sorry @SilentGhost, I didn't seen your comment at the bottom of the review. With this patch is microsecond is 0, the time will display 6 zeroes. -- Added file: http://bugs.python.org/file41388/issue19475_v8.patch

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by Alessandro Cucci : Added file: http://bugs.python.org/file41387/issue19475_v7.patch ___ Python tracker ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

SilentGhost added the comment: I think the patch is nearly finalised, but I'd appreciate if someone else would carefully go over the new C code. After that, I think, the patch could be committed. -- ___ Python tracker

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Uploaded a new patch after SilentGhost review comments. As he told me, I've left out milliseconds and nanoseconds, but refactored both python and c code so we could easily add support for them when they will be available. -- Added file:

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Uploaded a new patch. This time I ran tests using: $ ./python -m test -v test_datetime and got no errors. I've written the c docstring, updated docs, and rewrote _format_time function. I know it's boring review this another time, but I'm doing my best.

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Martin Panter added the comment: If the timespec allowed any arbitrary number of digits after the decimal point, that would remove any argument about nanoseconds not being supported. It would also mean I could use this in one case where I currently format to two decimal places (my compromise

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Changes by SilentGhost : -- nosy: +SilentGhost ___ Python tracker ___ ___

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Martin Panter added the comment: With patch v4 many tests still fail for me. How are you running the test suite? Some excerpts: File "/media/disk/home/proj/python/cpython/Lib/test/datetimetester.py", line 1567, in test_isoformat self.assertEqual(t.isoformat(timespec='milliseconds'),

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

SilentGhost added the comment: Even that produces 3 failures on my setup, though the full list would be available when running: ./python -m test -v test_datetime It is obvious, however, that the tests would fail: you've changed "if us:" to "if us is None:". --

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: Uploaded a new patch (v4): DONE: - now all tests work (I also added one more) - removed non ascii chars - added milliseconds and nanoseconds as multiple of microseconds - removed code duplication in the datetime.py - update the docstring. TODO: > The doc

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alessandro Cucci added the comment: I just did that... ~/Documenti/cpython$ ./configure --with-pydebug ~/Documenti/cpython$ make -s -j2 ~/Documenti/cpython$ ./python -m test -v datetimetester ... ... -- Ran 325 tests in 1.128s

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

' will be the most popular option, since HH:MM is the precision that most people care about for meetings and stuff. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision

Alexander Belopolsky added the comment: It looks like issue19475_v3.patch uses some fancy Unicode quotes in the docstrings and .rst docs. Please change them to ASCII. -- ___ Python tracker

<    1   2   3   4   5   6   7   8   >