[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Minor Success Story!

From: Andrew Janke
Subject: Re: Minor Success Story!
Date: Tue, 10 Aug 2021 15:59:36 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

On 8/10/21 3:51 PM, Nicholas Jankowski wrote:
On Tue, Aug 10, 2021 at 11:35 AM Clark Dunson <> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]