[Octave-bug-tracker] [bug #54374] datenum Matlab compatibility

[Rik]

Update of bug #54374 (project octave):

        Operating System:                  Mac OS => Any                    

    _______________________________________________________

Follow-up Comment #1:

It seems like this is correct behavior.  The format code is 'FFF' specifying
3-digits which doesn't match the string itself which has 6 digits.  Shouldn't
the programmer, who has more information about the original data, be
truncating the string, rather than Matlab or Octave?

As an example, consider using yy versus yyyy code assuming the year 2000.


octave:10> datenum('00-05-22T10:560:35.928', 'yy-mm-ddTHH:MMM:SS.FFF')
ans =  730628.41708
octave:11> datenum('00-05-22T10:560:35.928', 'yyyy-mm-ddTHH:MMM:SS.FFF')
ans =  143.42


Two very different results depending on the format.  I don't see why Octave
should know that the extra '000' can be safely ignored.

Out of curiosity, what does Matlab do for 


x1 = datenum('2006-05-22T10:56:35.928975', 'yyyy-mm-ddTHH:MM:SS.FFF') 
x2 = datenum('2006-05-22T10:56:35.928000', 'yyyy-mm-ddTHH:MM:SS.FFF') 
x1 - x2


Are they ignoring the microseconds or processing them?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54374>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/