the Gravity of Python 2

Roy Smith roy at panix.com
Thu Jan 9 09:14:22 EST 2014


In article <mailman.5244.1389254198.18130.python-list at python.org>,
 Chris Angelico <rosuav at gmail.com> wrote:

> What can you (Roy), with your use-case, achieve with datetime that 
> you can't achieve (at least reasonably easily) with a timestamp?

As I'm mentioned several times, when you print a datetime, you get 
something that's human friendly.  When you print a timestamp (i.e. a 
float), you get a lot of digits.  I don't know about you, but I can't 
look at 1389274842 and get any feel for whether that was in the middle 
of the night or at 5 in the afternoon, near our peak traffic time.  Nor 
can I tell if it was today, yesterday, last month, or a week from next 
Tuesday.

Datetimes make it easy to do things like, "find the time of the 
preceding (or following) midnight".  Or, "what month is this timestamp 
part of?"  These are operations we need to do a lot, to answer questions 
like, "How many unique users did we have on a given day?", or "Which 
monthly database archive file do I need to grab to get information about 
this historical event?"

Datetimes are self-documenting.  If I'm in the python shell and have 
something called t, I can do help(t) or dir(t) to find out what 
operations it has.

Datetimes are self-describing.  If I have a datetime or a timedelta, I 
know what I've got.  I've written more than one bug where I assumed a 
number somebody handed me was in seconds but it turned out to be in ms.  
That can never happen with a timedelta.  We do a lot of stuff in 
javascript, where times are ms, so this is a common problem for us.

Oh, and another thing I can do with a datetime that I can't do with a 
unix timestamp.  I can represent the day I was born.



More information about the Python-list mailing list