[Octave-bug-tracker] [bug #64563] datevec: "mmm dd yyyy" matched instead of "mmmyyyy" standard format

[Philip Nienhuis]

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

Both Matlab and Octave accept numeric 28 for datestr.m's 2nd argument
FormatOut, i.e. 'mmmyyyy', and neither Matlab's nor Octave's datevec.m have a
matching builtin format.
One can interpret this as "glitch-for-glitch" Matlab-compatibility of
datevec.m.
If datevec.m cannot properly parse a builtin output format produced by
datestr.m, IMHO that wouldn't fit with the principle of "least surprise". An
unwary user would expect to be each other's complement to some extent, I
suppose.
> At the moment, it's unclear to me if that could break existing code.
Nor to me. But as AFAIK the output of datevec ('mmmyyyy') hasn't been
documented, I doubt if relying on specific behavior of datevec.m for such
input would be good practice in the first place. So I think we can safely
patch datevec.m to accept 'mmmyyyy' input.
My patch would still need a bit more polishing (a.o., BIST).


I'm looking into other non-matches between datestr.m and datevec.m as well.
E.g., Matlab's datevec.m won't accept '2023' (output of "datestr ([2023, 1,
1], 10)") while Octave's returns [2023, 1, 0, 0, 0, 0]. I'd say Octave does
"better" here, apart from a day value of zero; Matlab's "datevec ('2023',
'yyyy')" returns [2023, 1, 1, 0, 0, 0]

I think the day value equal to 0 for some formats should be fixed as well but
would need another bug report.



    _______________________________________________________

Reply to this item at:

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

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