[Numpy-discussion] RFC: A proposal for implementing some date/time types in NumPy

[Francesc Alted]

A Saturday 12 July 2008, Jon Wright escrigué:
> Charles R Harris wrote:
> > On Fri, Jul 11, 2008 at 12:37 PM, Francesc Alted
> >
> >     A Friday 11 July 2008, Francesc Alted escrigué:
> >     >  A Friday 11 July 2008, Jon Wright escrigué:
> >     >  > Nice idea - please can you make it work with matplotlib's
> >     >  > time/date
> >     >
> >     >  Hmmm, following the matplotlib docstrings:
> >     >
> >     >  """
> >     >  datetime objects are converted to floating point numbers
> >     >  which represent the number of days since 0001-01-01 UTC
> >     >  """
>
> ...
>
> >     >  this more carefully, but I suppose that if there is interest
> >     > enough that could be implemented, yes.
> >
> >     Now that I think about this, wouldn't be better if, after the
> > eventual introduction of the new datetime types in NumPy, the
> > matplotlib would use any of these three and throw away their
> > current datetime class? [Unless they have good reasons for keeping
> > their epoch and/or scale]
> >
> > Especially as there was a ten day adjustment made with the adoption
> > of the Gregorian calender on Oct 4, 1582; early dates can be hard
> > to interpret. Curiously, IIRC, 01/01/0001 was a Monday.
>
> So I think I will just want to plot timeseries without (ever please)
> caring about date formats again. If you're proposing a "new" format
> then I'm assuming you want me to once again care that:
>
> 1) my temperature logger is recording data in Romance Standard Time,
> but not saying so, just day/month/year : time.
> 2) When we read that data we cannot tell which time zone it was
> recorded in, even if we think we remember where the logger was when
> it logged. 3) That the program I am running could currently be in any
> time zone 4) Whether the program is plotting compared to "now" in the
> current time zone or "then" that the data were recorded.
>
> None of these problems are new, or indeed unique, I think we only
> want a to_ and from_ converter to "what we mean" that we can plot,
> using matplotlib.

Well, timezones are a hairy issue.  From the docstrings of the Python's 
``datetime`` module:

"""
Supporting timezones at whatever level of detail is required is up to 
the application. The rules for time adjustment across the world are 
more political than rational, and there is no standard suitable for 
every application.
"""

In fact, the approach for the ``datetime`` module is that the user has 
to provide a concrete class (derived from the abstract ``tzinfo`` 
class) with *user-defined* methods that are supposed to do the 
necessary computations to convert UTC <--> 'localtime' timestamps.

However, doing the same in NumPy itself would be prohibitive in terms of 
computational effort.  So, our intention was to ignore this part of the 
reality (timezones) by always working internally with UTC time and let 
the user do the necessary conversions by using the machinery (together 
with user's own methods) that provides the ``datetime`` module.

We really think that this is a sensible way to proceed with timezones in 
the NumPy context.

> Timezones are a heck of a problem if you want to be accurate. You are
> talking about nanosecond resolutions, however, atomic clocks in orbit
> apparently suffer from relativistic corrections of the order 38000
> nanoseconds per day [1]. What will you do about data recorded on the
> international space station? Getting into time formats at this level
> seems to be rather complicated - there is no absolute time you can
> reference to - it is all relative :-)

Wow, this is really a much larger jitter than I expected.  I suppose 
that this reinforces the decision of deprecate the use of the TAI 
standard just for improving the precision in large time spans.

Thanks,

-- 
Francesc Alted