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

## ···