Possibly. So far we have a doc patch warning pushed and marked as ready and then some inconclusive beck and forth over whether there should be an actual code change or not.  if it's just going to stop at a doc fix then yes it can be closed.

> I'm not sure if it is possible in principle that datevec can correctly match all formats that have a numeric identifier in datestr.

Yeah I'm also unsure (just started investigating, then real life stepped in) but we can at least try to match as much as possible (or reasonable).

>It took me a while to notice that "AUG2013" can be matched by the pattern 'mmm dd yyyy'.

That's what this bug report is about. I suppose datevec.m should catch & if needed preprocess input before handing over to strptime(). Easiest is to provide a new format matching one in datestr.m.

strptime() is a beast and on top of that its behavior is partly implementation-defined (I hit that in the past that when trying to fix daylight saving time issues). So yes, surprises are due ...

I'm not so afraid of surprises if they pertain to undocumented behavior.
I'm more concerned (but not that much) with consistency of functions that provide, or implicitly or explicitly suggest to provide, each other's inverse, like datestr.m and datevec.m.

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.

comment #7:

> > Not sure which inconsistency you mean.
> See 2nd verbatim block in my comment #5

Could you please elaborate? I still don't understand what is inconsistent there...

Yeah, I quoted that part on purpose. I was hoping a native speaker could come up with something more technical. Maybe, something along the lines of:

> If no format string is provided, heuristics are used to guess the input format.

And if that is not clear enough, we could follow with something like:

> These heuristics might not give the expected result.

Not sure which inconsistency you mean.
In Matlab R2023a:

>> dstr = datestr (datenum ([2013, 8, 1, 0, 0, 0]), 28)
dstr =
    'Aug2013'
>> datevec(dstr, 'mmmyyyy')
ans =
        2013           8           1           0           0           0

For the roundtrip to work, you'd need to use the same (or equivalent) format specifiers in both directions.
Or if you don't want to use format specifiers, you must not use them in both directions:

>> dstr = datestr (datenum ([2013, 8, 1, 0, 0, 0]))
dstr =
    '01-Aug-2013'
>> datevec(dstr)
ans =
        2013           8           1           0           0           0

Format "29" was a typo. I meant to write "28". Which Matlab incompatibility are you referring to?

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.

there are a number of dates where Octave's datevec uses 0 as the starting day instead of 1.  don't have them linked but there were other bug conversations about that point so i didn't call it out here.

Octave output appears to partially match an format undefined by datestr or mentioned within datevec, but it isn't expanding two digit year to yyyy in the vector.

Octave 9.0.0 (hg id: caef3e5f755e)

>> datevec("AUG2013", 'mmmyyyy')
ans =

   2013      8      1      0      0      0

 datevec("AUG2013", 'mmmddyy')
ans =

   2013      8     20      0      0      0

>> datevec("AUG2013")
ans =

   13    8   20    0    0    0

matlab 2023a behavior isn't much help here.  probably should file a mathworks bug:

>> datevec("AUG2013", "mmmyyyy")
ans =
        2013           8           1           0           0           0
>> datevec("AUG2013", "mmmddyy")
ans =
        2013           8          20           0           0           0
>> datevec("AUG2013")
ans =
        2029           2           2           0           0           0

since mmmyyyy is one of the specified standard datestr formats, I would think the matching routine should find that one first.