[ python-Feature Requests-414059 ] Floating point second in date/time tuple

[SourceForge.net]

Feature Requests item #414059, was opened at 2001-04-05 19:33
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Tim Cera (timcera)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating point second in date/time tuple

Initial Comment:
Would like to have this:

>>> time.localtime(1057035600.6)
(2003, 7, 1, 1, 0.6, 0, 1, 182, 1)

Instead of:

>>> time.localtime(1057035600.6)
(2003, 7, 1, 1, 0, 0, 1, 182, 1)


At a minimum the fractional seconds should be rounded
instead of truncated.

thanks
tim cera

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-09 10:06

Message:
Logged In: YES 
user_id=80475

Agree with Brett. 
Closing this one.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-13 00:55

Message:
Logged In: YES 
user_id=357491

The problem is that the C library's localtime is used to do the conversion and 
that takes in a time_t argument.  On almost all platforms this is a long int.  
Forcing the number to an integer prevent any unexpected warning about 
casting if the platform does support floats for some odd reason.

The reason the argument is truncated is because the argument to 
PyArg_ParseTuple is 'd', which is integer.  Python basically does what C 
would do which is truncate.  You could round it up by taking the number as 
a Python object, 
calling Python's round function, and then extract the integer after the 
rounding.  Trouble is that now your value accounts for time that you didn't 
even have.  The plus side to truncating is your are not adding on time that 
did not occur; you are just losing some extra time you had.  =).

If you want to create a patch to rectify the situation you might get people to 
support the idea, but I don't view this as critical, especially when you can call 
round yourself before passing the value to localtime.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470