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