Re: problem parsing time out of datetime object

[PhilipNienhuis]

NJank wrote
> On Fri, Oct 20, 2017 at 3:41 PM, PhilipNienhuis <

> pr.nienhuis@

> >
> wrote:
> 
>> AG wrote
>> > I am trying to parse a datetime string into two pieces, date and time,
>> and
>> > I'm trying to figure out why this code does not work.  According to the
>> > docs
>> > it seems that a call to rem on a datetime will give you the time but it
>> > doesn't seem to do that.
>> >
>> > dt_num = datenum('2013/05/29 00:00:00','YYYY/DD/MM HH:MM:SS')
>> >
>> >  d_num = floor(dt_num)
>> >  t_num = rem(dt_num,1)
>> >
>> > datestr(d_num) ## ans = 05-Jan-2013  (RIGHT!)
>> > datestr(t_num)  ## ans = 31-Dec--001 (WRONG)
>>
>> Seems perfectly OK to me. What else would you expect for a date in the
>> year
>> 0, month 0, day 0?  :-)
>>
>> But perhaps you meant:
>> >> datestr (t_num, 13)
>> ans = 00:00:00
>>
>> (try "help datestr" to see datestr's output options)
>>
>> Philip
>>
>>
> I would also suggest being careful with your upper and lower case format
> declarations. Octave is more forgiving than matlab, but usually the date
> should be lower case and the time upper case.  Also, did you mean to
> specify day = 5, month = 29? This can cause unintended results.
> 
> when there is no format specified for datestr, it tries to guess at the
> form to use. help says it chooses between 0, 1, or 16 depending on whether
> the date or time portion (portion before or after the decimal point) are
> empty. so:
> 
> xxx.xxx -->  dd-mmm-yyyy HH:MM:SS
> xxx.0 -->  dd-mmm-yyyy
> 0.xxx -->  HH:MM:SS
> 
> This works correctly for non-zero time (try with any other time and the
> last command does just give the time). apparently, it interprets 0.0 as
> the
> second case, and displays the date '0', or 31 DEC 0001.  matlab interprets
> this as '00-Jan-0000'

Admittedly the automatic format detection could be better, yes. 
datestr(0) isn't a clear corner case.

datestr (0 + eps) correctly gives
ans = 12:00 AM

In L. 205-213 of datestr.m it seems that (at least for this case) the
if/elseif clauses are in the wrong order. Swapping the if and the first
elseif conditions & clauses makes datestr behave better while it still
PASSes all 40 tests. But this should be given more thought - the current
if/elseif/else order probably has some reasoning behind it, right or wrong.

In addition the help text could be a little more clear. 

Maybe file a bug report?

Philip




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-General-f1599825.html