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.

classification
Title: timestamp() method for datetime objects
Type: Stage:
Components: Extension Modules Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: catlee, davidfraser, gvanrossum
Priority: normal Keywords: patch

Created on 2006-03-23 20:06 by catlee, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
datetime.patch catlee, 2006-03-23 20:06 datetime.patch
Messages (5)
msg49841 - (view) Author: Chris AtLee (catlee) * Date: 2006-03-23 20:06
This patch adds a timestamp() method to datetime
objects.  It is equivalent to:
time.mktime(self.timetuple())

I pulled out the dstflag calculation code from
datetime_timetuple into a new function, get_dstflag, so
that datetime_timestamp can make use of the same code.

The patch also includes updates to the datetime
documentation, and a simple unit test.
msg49842 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2006-03-23 20:23
Logged In: YES 
user_id=6380

I'm against this functionality.

It suggests an linkage between the "naive"
(timezone-unaware) time carried in the datetime object, and
the UTC space that posix timestamps represent.  The entire
point of the datetime type (unless an explicit tzinfo is
passed) is that it doesn't know which timezone it represents.

When you call time.mktime(self.timetuple()), you as the
application make the determination that the timetuple (which
is still tz-unaware!) represents your current local time. 
That's a fine decision for the app to make.  But I don't
think users should be lured into believing there's an
equivalency inherent in the datetime type -- there isn't.
msg49843 - (view) Author: Chris AtLee (catlee) * Date: 2006-03-23 21:37
Logged In: YES 
user_id=186532

The .fromtimestamp and .utcfromtimestamp class methods
already imply this linkage, don't they?

What if timestamp() only works if the datetime object isn't
"naive"?

msg49844 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2006-03-23 21:41
Logged In: YES 
user_id=6380

Well, that they both exist implies that the linkage is
ambiguous...

I think it's just not worth the new API given that it's (as
you admit) just a shorthand for two other calls.

There's also the problem that the range for timestamps is
much smaller than the range of datetime -- this isn't a
problem for .[utc]fromtimestamp() but is a problem for the
reverse API.
msg49845 - (view) Author: David Fraser (davidfraser) Date: 2006-09-16 19:43
Logged In: YES 
user_id=221678

I know this is closed...
I think it would be helpful to either
1) add a description to the documentation of how to convert
back, explaining the timezone story
2) add a timestamp() function that takes a timezone parameter
History
Date User Action Args
2022-04-11 14:56:16adminsetgithub: 43077
2006-03-23 20:06:07catleecreate