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 skip.montanaro
Recipients guettli, jribbens, skip.montanaro, tim.peters
Date 2007-09-02.16:07:11
SpamBayes Score 0.19411157
Marked as misclassified No
Message-id <18138.57258.603974.168649@montanaro.dyndns.org>
In-reply-to <1188741790.25.0.67967017151.issue1673409@psf.upfronthosting.co.za>
Content
Jon> Almost everything you just said about time_t is wrong. time_t is
    Jon> signed, and always has been (otherwise the 'end of time' for 32-bit
    Jon> time_t would be 2106, not 2038). Also, time_t does not end at 2038
    Jon> because nothing says it must be 32 bits. Also, Python has 'long
    Jon> integers' which do not overflow.

My apologies about goofing up on the signedness of time_t.  What are you
going to do with a long integer that you can't do with a datetime object?
You clearly can't pass it directly to any Unix library functions which
expect time_t.  Converting it can overflow.

    Jon> Also, I don't understand what you mean about use cases. The "use
    Jon> case" is "dealing with anything which expects standard Unix time_t,
    Jon> for example the Python standard library". The use case I have
    Jon> personally is the program I was working on when I encountered the
    Jon> problem described in this bug report. Also I think symmetry is a
    Jon> darn good argument. Why does fromtimestamp exist if, as you claim,
    Jon> nobody uses time_t?

What should datetime.datetime(9999, 1, 1).totimestamp() return?  How would
you pass it to something which accepts a time_t?  The fromtimestamp
functions work simply because the range of time_t is a proper subset of the
range of Python's datetime objects.  Symmetry gets you little.  In
situations where you need Unix timestamps and you know your datetime objects
are within the bounds representable by time_t, you can define a convenience
function:

    def totimestamp(dt):
        return time.mktime(dt.timetuple()) + dt.microsecond/1e6

This will, of course, fail if the year is too big or too small (and will
fail in platform-dependent ways if the underlying platform's range of
representable dates has different bounds than Unix does).  Doing it without
resorting to calling time.mktime is also nontrivial.  Under the covers the
datetime module currently uses platform functions to get time information
anyway.  It doesn't do a lot of low-level time arithmethic itself.
Implementing fromtimestamp would require a fair amount of effort unless you
were willing to punt and just raise OverflowError for dates outside the
system's range.

Skip
History
Date User Action Args
2007-09-02 16:07:12skip.montanarosetspambayes_score: 0.194112 -> 0.19411157
recipients: + skip.montanaro, tim.peters, jribbens, guettli
2007-09-02 16:07:11skip.montanarolinkissue1673409 messages
2007-09-02 16:07:11skip.montanarocreate