[Octave-bug-tracker] [bug #36954] datenum converts date string incorrectly during DST start

[Philip Nienhuis]

Update of bug #36954 (project octave):

                  Status:               Confirmed => Patch Submitted        
             Assigned to:                    None => philipnienhuis         

    _______________________________________________________

Follow-up Comment #12:

cset attached including test.

Admittedly it is a bit kludgy but the most reliable way I could come up with
is to 
- reconstruct the original time string with strftime from strptime's output,
and
- compare that with the original string
while both have been stripped of spaces and zero digits, to get rid of a.o.,
leading zeros and extra spaces introduced by strftime (see below).

I've run "make check" with this cset applied to my local repo to check if any
other date/time related output is affected; no FAILs were introduced by it so
I consider this patch fairly safe :-)

IMO strptime isn't the most suited tool to parse date/time strings due to this
DST issue, but as it is probably the only efficient tool available we'll have
to make do with it.


BTW, I noted that the internal format string fed to strptime can sometimes be
off in the sense that it adds leading zeros that weren't in he original
date/time string, e.g., by using %H rather than %j; while in turn  %j
introduces an extra space instead of a zero digit. 
But as those internal formats aren't exposed I didn't investigate further.


(file #38336)
    _______________________________________________________

Additional Item Attachment:

File name: bug_36954_datevec_DST.cset     Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36954>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/