datetime module missing some important methods

[jribbens]

BPO	1673409
Nosy	@tim-one, @smontanaro, @jribbens, @srittau, @amauryfa, @mdickinson, @pitrou, @catlee, @vstinner
Superseder	bpo-2736: datetime needs an "epoch" method
Files	timedelta.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-04-21.18:03:30.573>
created_at = <Date 2007-03-04.11:59:05.000>
labels = ['type-feature', 'library']
title = 'datetime module missing some important methods'
updated_at = <Date 2010-04-21.18:52:38.900>
user = 'https://github.com/jribbens'

bugs.python.org fields:

activity = <Date 2010-04-21.18:52:38.900>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2010-04-21.18:03:30.573>
closer = 'mark.dickinson'
components = ['Library (Lib)']
creation = <Date 2007-03-04.11:59:05.000>
creator = 'jribbens'
dependencies = []
files = ['8837']
hgrepos = []
issue_num = 1673409
keywords = ['patch']
message_count = 39.0
messages = ['55042', '55043', '55573', '55585', '55586', '57050', '57051', '57052', '57057', '57058', '57059', '57078', '57080', '58007', '58009', '58068', '69516', '75408', '75410', '75411', '75423', '75426', '75724', '75754', '75859', '75860', '75863', '77859', '77861', '77862', '77865', '77867', '77868', '77869', '77871', '103868', '103874', '103878', '103888']
nosy_count = 14.0
nosy_names = ['tim.peters', 'skip.montanaro', 'jribbens', 'srittau', 'guettli', 'amaury.forgeotdarc', 'mark.dickinson', 'pitrou', 'catlee', 'vstinner', 'tomster', 'erik.stephens', 'steve.roberts', 'Alexander.Belopolsky']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '2736'
type = 'enhancement'
url = 'https://bugs.python.org/issue1673409'
versions = ['Python 2.7']

[jribbens]

The datetime module is missing some important methods for interacting with timestamps (i.e. seconds since 1970-01-01T00:00:00).

There are methods to convert from a timestamp, i.e. date.fromtimestamp and datetime.fromtimestamp, but there are no methods to convert back.

In addition, timedelta has no method for returning the number of seconds it represents (i.e. days*86400+seconds+microseconds/1000000).

[guettli]

Yes, that's true.

[smontanaro]

There is no datetime.totimestamp because the range
of time represented by a datetime object far
exceeds the range of a normal int-based Unix
timestamp (roughly 1970-2038). Datetime objects
before the start of the Unix epoch would be
represented by negative numbers. As far as I
know, the common Unix library functions which
accept epoch times wouldn't know what to do
with a negative number.

That said, you stated these missing methods
were important. Can you offer some use
cases which would support that contention?
I personally don't think a argument for
symmetry would be a convincing use case and
that's the only one I can think of.

[jribbens]

Almost everything you just said about time_t is wrong. time_t is signed,
and always has been (otherwise the 'end of time' for 32-bit time_t would
be 2106, not 2038). Also, time_t does not end at 2038 because nothing
says it must be 32 bits. Also, Python has 'long integers' which do not
overflow.

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

[smontanaro]

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

[tomster]

unless I'm missing something important this will do the trick quite
nicely:

    >>> from datetime import datetime
    >>> datetime(2007, 12, 24, 20, 0).strftime("%s")
    '1198522800'

For most imaginable use cases, where an epoch style time stamp is
required this should be enough.

HTH,

Tom

[smontanaro]

Tom> unless I'm missing something important this will do the trick quite
Tom> nicely:

    >>>> from datetime import datetime
    >>>> datetime(2007, 12, 24, 20, 0).strftime("%s")
    Tom>     '1198522800'

Tom> For most imaginable use cases, where an epoch style time stamp is
Tom> required this should be enough.

No fractions of a second...

Skip

[jribbens]

No fractions of a second...

If we're expecting floating-point, then everything you said earlier
about the limitations of ints was a bit redundant ;-)

[smontanaro]

> No fractions of a second...

Jon> If we're expecting floating-point, then everything you said earlier
Jon> about the limitations of ints was a bit redundant ;-)

Yes, sorry. I responded to the mail without going back and reviewing the
entire thread. (It's been a couple months.) Note however that my example
to_timestamp() function converts the microseconds field to seconds and
include them in the result.

So, are we concluding that nothing needs to be added to the datetime module?

Skip