This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients belopolsky, elixir, ezio.melotti, gvanrossum, lemburg, r.david.murray, skip.montanaro, terry.reedy, tim.peters, vstinner
Date 2013-11-06.17:05:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 06.11.2013 16:51, Alexander Belopolsky wrote:
> MAL: Have you thought about the rounding/truncation issues
> associated with not showing microseconds ?

Sure, otherwise I wouldn't have mentioned it :-)

mxDateTime always uses 2 digit fractions when displaying date/time values.
This has turned out to be a good compromise between accuracy and
usability. In early version, I used truncation, but that caused
(too many) roundtrip problems, so I started using careful rounding
in later versions:

/* Fix a second value for display as string.

   Seconds are rounded to the nearest microsecond in order to avoid
   cases where e.g. 3.42 gets displayed as 03.41 or 3.425 is diplayed
   as 03.42.

   Special care is taken for second values which would cause rounding
   to 60.00 -- these values are truncated to 59.99 to avoid the value
   of 60.00 due to rounding to show up even when the indicated time
   does not point to a leap second. The same is applied for rounding
   towards 61.00 (leap seconds).

   The second value returned by this function should be formatted
   using '%05.2f' (which rounds to 2 decimal places).


This approach has worked out well, though YMMV.

> I believe it has to be the truncation.  Rounding is better left to the user code where it can be done either using timedelta arithmetics or at the time source.  I would expect that in the majority of cases where lower resolution printing is desired the times will be already at lower resolution at the source.

In practice you often don't know the resolution of
the timing source. Nowadays, the reverse of what you said
is usually true: the source resolution is higher than the
precision you use to print it.

MS SQL Server datetime is the exception to that rule, with a
resolution of 333ms and weird input "rounding":

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.
Date User Action Args
2013-11-06 17:05:26lemburgsetrecipients: + lemburg, gvanrossum, tim.peters, skip.montanaro, terry.reedy, belopolsky, vstinner, ezio.melotti, r.david.murray, elixir
2013-11-06 17:05:25lemburglinkissue19475 messages
2013-11-06 17:05:25lemburgcreate