bugGNU Octave - Bugs: bug #42241, datevec() should allow partial...

 
 

bug #42241: datevec() should allow partial matches when format is specified

Submitter:  Ben Kurtz <bkurtz>
Submitted:  Wed 30 Apr 2014 08:00:40 AM UTC
   
 
Category:  Octave Function Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  9.1.0 Planned Release:  9.1.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 13 Oct 2023 07:07:44 PM UTC, comment #11: 

No complaints in two months. Closing as fixed.

Arun Giridhar <arungiridhar>
Group Member
Thu 17 Aug 2023 08:35:58 PM UTC, comment #10: 

ok, pushed http://hg.savannah.gnu.org/hgweb/octave/rev/276aa68a290d

that makes the Ben's change.  notes the behavior in the docstring, and added a suite of tests for all the standard formats defined in datestr and datevec, checking regular resolution, resolution when format supplied, and continued resolution when presented with either an anomalous datestring or just added extraneous chars.
 
marking as ready for test.


Nicholas Jankowski <nrjank>
Group Member
Tue 15 Aug 2023 08:46:49 PM UTC, comment #9: 

that should be reasonable.  It passes all existing tests, but I'll try to generate a set that tests each of the predefined formats with/without extra characters, etc.

Nicholas Jankowski <nrjank>
Group Member
Tue 15 Aug 2023 08:04:54 PM UTC, comment #8: 

IMO what Matlab does here seems "reasonable" behavior to me.

I'd like to be sure that all predefined date/time formats wil still work fine wih the patch.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 15 Aug 2023 02:08:35 AM UTC, comment #7: 

looking to answer my question about ambiguities and ignoring the issue of 'extraneous trailing characters', i looked at the first two standard datestring formats:

  1. dd-mmm-yyyy HH:MM:SS 07-Sep-2000 15:38:09

1 dd-mmm-yyyy          07-Sep-2000

currently in Matlab, specifying the second type when presented with the first gives you a valid answer with the date components requested since there is a partial match:

Matlab 2023a:

>> datevec('2013-08-01 08:00:00','yyyy-mm-dd HH:MM:SS')
ans =
        2013           8           1           8           0           0
>> datevec('2013-08-01 08:00:00','yyyy-mm-dd')
ans =
        2013           8           1           0           0           0


in Octave this gives an error:

octave:1> datevec('2013-08-01 08:00:00','yyyy-mm-dd HH:MM:SS')
ans =

   2013      8      1      8      0      0

octave:2> datevec('2013-08-01 08:00:00','yyyy-mm-dd')
error: datevec: DATE not parsed correctly with given format
error: called from
    datevec at line 155 column 11


Absent objections, I think this should become standard Octave behavior as well, including documentation. i'll work up some possible docstring text to add to the patch.

Nicholas Jankowski <nrjank>
Group Member
Mon 14 Aug 2023 09:29:33 PM UTC, comment #6: 

reading through the matlab documentation confirms that this is an undocumented matlab behavior case.  It has been stable behavior for a decade or more if we just go off the date on this bug. I saw some other forum posts that suggest this behavior goes farther back, but didn't dig too deep.

I would still lean toward including this behavior in Octave's datevec, but would want some input on others if they think there are any potential problems it could introduce. are there places it would match but it shouldn't? or any ambiguity in matching that could occur, and for which extra BISTs could cover?

Nicholas Jankowski <nrjank>
Group Member
Sat 12 Aug 2023 04:51:54 PM UTC, comment #5: 

i refreshed the patch and included BISTs and a note to the NEWS file. change doesn't seem to cause any other problems, passes a make check on the latest default.

I haven't looked enough to see if this is documented or undocumented matlab behavior, so i'm just attaching the patch here rather than pushing right away.  it seems to have been stable matlab behavior for some time.  so if no one objects, i think it would be worthwile to  push to default for octave 9.

(file #55029)

Nicholas Jankowski <nrjank>
Group Member
Sat 12 Aug 2023 12:15:23 AM UTC, comment #4: 

Issue is still present in octave 9.0.0 (hg id: 28562a1b2fcb)


octave:1> datevec('2013-08-01 08:00:00/xyzpdq')
error: datevec: none of the standard formats match the DATE string
error: called from
    datevec at line 145 column 11
octave:2> datevec('2013-08-01 08:00:00/xyzpdq','yyyy-mm-dd HH:MM:SS')
error: datevec: DATE not parsed correctly with given format
error: called from
    datevec at line 155 column 11


in matlab 2023a:


>>  datevec('2013-08-01 08:00:00/xyzpdq')
Error using datevec
Failed to lookup month of year.

>> datevec('2013-08-01 08:00:00/xyzpdq','yyyy-mm-dd HH:MM:SS')

ans =

        2013           8           1           8           0           0


supplied patch no longer applies clean to default. changing to in progress.

Nicholas Jankowski <nrjank>
Group Member
Wed 04 Aug 2021 07:38:09 PM UTC, comment #3: 

This issue is still present in Octave 6.1.0.


datevec('2013-08-01 08:00:00/xyzpdq')
error: datevec: none of the standard formats match the DATE string
error: called from
    datevec at line 139 column 11

datevec('2013-08-01 08:00:00/xyzpdq','yyyy-mm-dd HH:MM:SS')
error: datevec: DATE not parsed correctly with given format
error: called from
    datevec at line 149 column 11


Anonymous
Thu 15 Dec 2016 03:03:25 PM UTC, comment #2: 

This issue is still present in Octave 4.2.0.

The second code line from comment #0 still throws an error in Ocave.

There is a proposal for a PATCH in comment #0.


Hartmut <hardy>
Wed 30 Apr 2014 08:01:59 AM UTC, comment #1: 

Also, I've done this a couple of times and I'm not sure what the best procedure is; for simple stuff like this, should I submit it as a 'bug' or a 'patch' in Savannah?

Ben Kurtz <bkurtz>
Wed 30 Apr 2014 08:00:40 AM UTC, original submission:  

In MATLAB if I specify the format for a date, anything that matches will parse:


>> datevec('2013-08-01 08:00:00/xyzpdq')
Error using datevec (line 213)
Failed to lookup month of year.

>> datevec('2013-08-01 08:00:00/xyzpdq','yyyy-mm-dd HH:MM:SS')

ans =

        2013           8           1           8           0           0


This is useful when:

  • date is part of a filename (don't have to write/run code to strip the tail end before parsing)
  • just want the date of a date/time string of known format


The current octave implementation throws errors for both calls, because it requires the full input string to match the format.

Attaching a patch that makes the behavior more like MATLAB, i.e. if a format is specified, the conversion will work as long as the string matches the format, even if there are extra characters at the end.

Ben Kurtz <bkurtz>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55029:  datevec_partialmatch.diff added by nrjank (3KiB - text/x-patch - updated patch)
file #31281:  datevec.patch added by bkurtz (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by bkurtz (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-10-13 arungiridhar StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 9.1.0
    2023-08-17 nrjank StatusNeed Info Ready For Test
    2023-08-14 nrjank StatusPatch Submitted Need Info
    2023-08-12 nrjank Attached File- Added datevec_partialmatch.diff, #55029
        StatusIn Progress Patch Submitted
        Planned ReleaseNone 9.1.0
    2023-08-12 nrjank StatusPatch Submitted In Progress
    2018-08-17 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupMatlab Compatibility Feature Request
        StatusNone Patch Submitted
    2014-04-30 bkurtz Attached File- Added datevec.patch, #31281

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code