[Python-Dev] datetime nanosecond support
vincenzo.ampolo at gmail.com
Wed Jul 25 10:03:58 CEST 2012
On 07/24/2012 08:47 PM, Guido van Rossum wrote:
> So what functionality specifically do you require? You speak in
> generalities but I need specifics.
The ability of thinking datetime.datetime as a flexible class that can
give you the representation you need when you need. To be more specific
think about this case:
User selects year, month, day, hour, minute, millisecond, nanosecond of
time of this format (variant of iso8601):
YYYY-MM-DDTHH:MM:SS.mmmmmmnnn (where nnn is the nanosecond representation).
The python server takes that string, converts to a datetime, does all
the math with its data and gives the output back using labeling data
with int(nano_datetime.strftime('MMSSmmmmmmnnn')) so I've a sequence
It's this flexibility of conversion I'm talking about.
>> As you may think using that approach in a web application is very
>> limiting since there is no strftime() in this custom class.
> Apparently you didn't need it? :-) Web frameworks usually have their
> own date/time formatting anyway.
Which is usually derived from python's datetime, like in web2py (
http://web2py.com/books/default/chapter/29/6#Record-representation ) in
which timestamps are real python datetime objects and It's ORM
responsability to find the right representation of that data at database
This lead, as you know, to one of the main advantages of any ORM:
abstract from the database layer and the SQL syntax.
The same applies for another well known framework, Django ( your
personal favorite :) ) in which DateTimeField (
) is a date and time
represented in Python by a datetime.datetime instance.
We didn't need to build a webapp yet. I've been hired for it :) So I'll
do very soon. Unluckly if datetime does not support nanoseconds, I
cannot blame any ORM for not supporting it natively.
>>> I didn't read the entire bug, but it mentioned something about storing
>>> datetimes in databases. Do databases support nanosecond precision?
>> Yeah. According to
>> http://wiki.ispirer.com/sqlways/postgresql/data-types/timestamp at least
>> Oracle support timestamps with nanoseconds accuracy, SQL server supports
>> 100 nanosecond accuracy.
>> Since I use Postgresql personally the best way to accomplish it (also
>> suggested by the #postgresql on freenode) is to store the timestamp with
>> nanosecond (like 1343158283.880338907242) as bigint and let the ORM (so
>> a python ORM) do all the conversion job.
>> An yet again, having nanosecond support in datetime would make things
>> much more easy.
> How so, given that the database you use doesn't support it?
Wasn't the job of an ORM to abstract from actual database (either
relational or not relational) such that people who use the ORM do not
care about how data is represented behind it?
If yes It's job of the ORM to figure out what's the best representation
of a data on the given relational or non relational database.
> TBH, I think that adding nanosecond precision to the datetime type is
> not unthinkable. You'll have to come up with some clever backward
> compatibility in the API though, and that will probably be a bit ugly
> (you'd have a microsecond parameter with a range of 0-1000000 and a
> nanosecond parameter with a range of 0-1000). Also the space it takes
> in memory would probably increase (there's no room for an extra 10
> bits in the carefully arranged 8-byte internal representation).
Sure, that are all open issues but as soon as you are in favour of
adding nanosecond support we can start addressing them. I'm sure there
would be other people here that would like to participate to those
> But let me be clear -- are you willing to help implement any of this?
> You can't just order a feature, you know...
Of course, as I wrote in my second message in the issue (
http://bugs.python.org/issue15443#msg166333 ) I'm ready and excited to
contribute to the python core if I can.
More information about the Python-Dev