Fair enough.
Thanks!

On Nov 17, 2008, at 1:06 PM, Eric Firing wrote:

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

------------------------------------------------------
Val Schmidt
CCOM/JHC
University of New Hampshire
Chase Ocean Engineering Lab
24 Colovos Road
Durham, NH 03824
e: vschmidt [AT] ccom.unh.edu
m: 614.286.3726



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to