[Octave-bug-tracker] [bug #64563] datevec: undefined mmmddyy partially matched instead of mmmyyyy standard format

[Markus Mützel]

Follow-up Comment #4, bug #64563 (project octave):

I guess Matlab interprets that input as the "2013th day of August" in the
current year:

>> datevec(datenum([2023 8 2013 0 0 0]))

ans =

        2029           2           2           0           0           0



Octave's behavior seems more reasonable to me. So, I don't see a reason to
follow Matlab's behavior in that case.

Stepping through the code in Octave, the input is matched to the format string
`mmm dd yyyy`. IIUC, that is because `[tm, nc] = strptime('AUG2013', '%b %d
%Y')` matches the entire input string (i.e., nc == 8).

That seems to be the behavior defined by POSIX for that function:
https://man7.org/linux/man-pages/man3/strptime.3.html
In particular:
> All other characters in the format string must have a matching character in
the input string, except for whitespace, which matches zero or more whitespace
characters in the input string.

It is not clear what the "correct behavior" of `datevec` would be in this
particular case. Are we sure that adding new strings to the format list
doesn't have unexpected side effect? (And if we do want to add it, it should
come with a comment that it's format type 29.)
The docstring already encourages to supply a date format for performance
reasons. Maybe, we should just add a note to the docstring that "all bets are
off" for ambiguous date strings if no format string is explicitly supplied.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64563>

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