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

Jon Wright wright@esrf...
Fri Jul 11 17:56:47 CDT 2008


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.

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 :-)

Thanks, and bon chance,

Jon

[1] http://www.phys.lsu.edu/mog/mog9/node9.html


More information about the Numpy-discussion mailing list