Re: Minor Success Story!

Andrew Janke <[email protected]> Tue, 10 Aug 2021 15:59:36 -0400
Newsgroups gmane.comp.gnu.octave.general
Message-ID <[email protected]>

On 8/10/21 3:51 PM, Nicholas Jankowski wrote:
> On Tue, Aug 10, 2021 at 11:35 AM Clark Dunson <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Today I ran into trouble with datenum('2021-07-21 09:00:00.987').
>     The fractional part. But what I soon found is that this:
>     datenum('2021-07-21 09:00:00.987','yyyy-mm-dd HH:MM:SS.FFF') works
>     just fine. (This is of course a primary use case of those who
>     would analyze SQL data.)
>     ...
>     Looking at datevec.m, none of the std_formats have FFF, so likely
>     enhancing the search (though it works on Matlab) makes no sense.
>     Does it? 
>
>
>  Generally there is resistance to trying to emulate 'undocumented
> matlab'.  the matlab docs dont specify any predefined formats
> including FFF.  But, it does provide for automatic recognition of the
> FFF string. So it appears that Matlab's autorecognition does
> understand the format, despite the datevec text saying: " If you do
> not specify |formatIn|, then |DateString| must be in one of the
> following formats..." (none of which include FFF)
>
> I don't think people would want to mess with the pre-defined formats,
> since they're a compatibility item.  There could be an argument made
> expanding the autorecognition, though.
>

My vote woudl be to go ahead and expand the autorecognition. Matlab's
datevec/datenum/datetime documentation has always been underpowered;
gotta do whatcha gotta do.

But please let's don't put a try/catch in the "happy" code path like
Matlab does in this area, that's just an own goal and gives me a frowny.

Cheers,
Andrew