[Patches] [ python-Patches-1457227 ] timestamp() method for datetime objects

[SourceForge.net]

Patches item #1457227, was opened at 2006-03-23 15:06
Message generated for change (Comment added) made by catlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&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: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris AtLee (catlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: timestamp() method for datetime objects

Initial Comment:
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.

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

>Comment By: Chris AtLee (catlee)
Date: 2006-03-23 16:37

Message:
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"?



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-23 15:23

Message:
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.

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

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