[issue15443] datetime module has no support for nanoseconds

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The following code demonstrates that we can pack year through second fields in 40 bits:

#include <stdio.h>
struct dt {
  unsigned year :14;   /* 1-9999 of 0-16,383 */
  unsigned month :4;   /* 1-12 of 0-16 */
  unsigned day   :5;   /* 1-31 of 0-31 */
  unsigned hour  :5;   /* 0-23 of 0-31 */
  unsigned minute:6;   /* 0-59 of 0-63 */
  unsigned second:6;   /* 0-59 of 0-63 */
  /* total :     40 bits */
};

int main() {
  struct dt t;
  t.year = 9999;
  t.month = 12;
  t.day = 31;
  t.hour = 24;
  t.minute = 59;
  t.second = 59;
  printf("%d-%d-%dT%d:%d:%d in %d bytes\n",
         t.year, t.month, t.day,
         t.hour, t.minute, t.second,
         (int)sizeof(t));
}

$ ./a.out
9999-12-31T24:59:59 in 8 bytes

Assuming 64-bit alignment, this leaves 64*2 - 40 = 88 bits for the sub-second field.

In 88 bits you can pack yoctoseconds (yocto = 1e-24) without breaking a sweat:

>>> 2**88
309485009821345068724781056
>>> 10**24
1000000000000000000000000

The practical choice is between 32-bit nanoseconds (nano = 1e-9) and 64-bit attoseconds (atto = 1e-18).

Given that the current the world record for shortest controllable time is 12 attoseconds [1], it may not be an absurd choice to go to 64 bits of sub-second precision.

On the other hand, if we manage to go from micro- to nano-seconds now, I don't think it will be hard to go to higher resolution when users start asking for it some 40 years into the future.


[1] http://phys.org/news192909576.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________