# [Python-bugs-list] [ python-Feature Requests-414059 ] Floating point second in date/time tuple

Sat Aug 9 02:06:12 EDT 2003

```Feature Requests item #414059, was opened at 2001-04-05 12:33
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470

Category: Python Library
Group: None
Status: Open
>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)

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

At a minimum the fractional seconds should be rounded

thanks
tim cera

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

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

Message:
Logged In: YES
user_id=80475

Agree with Brett.
Closing this one.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 17: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

```