vschmidt wrote:
I'm hoping you can help me confirm/deny a bug in pylab's date2num() function.
My assumption (this may be wrong) is that this function is meant to be
compatible with the MATLAB function date2num(). However, in ipython I can
execute:
---------
import datetime
import pylab as p
dts = datetime.datetime.now()
serialts = p.date2num(dts)
print dts
2008-11-16 12:03:20.914480
print serialts
733362.502325
------------
If I then copy this serialts value into MATLAB I get:
----------
datestr(733362.502325)
16-Nov-2007 12:03:20
----------
Note that the year is off by one.
Evidently date2num was designed to be similar, but not identical, to Matlab's datenum. (The difference might have been inadvertent.) Matlab's documentation says,
A serial date number represents the whole and fractional number of days from a specific date and time, where datenum('Jan-1-0000 00:00:00') returns the number 1. (The year 0000 is merely a reference point and is not intended to be interpreted as a real year in time.)
And mpl's says,
return value is a floating point number (or sequence of floats)
which gives number of days (fraction part represents hours,
minutes, seconds) since 0001-01-01 00:00:00 UTC
So they simply have a different origin. I find calendars endlessly confusing, and I make no attempt to delve into them; but I dimly recall that there is a year 1, but there is no year 0, so perhaps that is an advantage of the mpl version--not that it should matter in practice.
I think the conclusion is that this sort of date number should be considered suitable for internal use only, and not used as an interchange format; for going from one software system to another, one must use a genuine standard supported by both.
Eric
···