patchGNU Octave - Patches: patch #9964, datevec.m: add some fairly often...

 
 

patch #9964: datevec.m: add some fairly often seen date/time formats

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Tue 04 Aug 2020 07:06:08 PM UTC
   
 
Category:  Core : other Priority:  5 - Normal
Status:  Ready For Test Privacy:  Public
Assigned to:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 05 Aug 2023 07:36:51 PM UTC, comment #5: 

Thanks Markus :-)

Yeah "contemporary" is a bit loosely, I didn't even realize these formats were standardized somewhere - but yes I could/should have expected that. Maybe be a reason to also add support for more yet unsupported formats. S/th for later on, once I hit them in the wild.

As to

> It shouldn't be possible for a variable to be undefined after it was used on the left-hand-side of an assignment.

ISTR that exactly that was the case - not so much "used" but more like "untouched". In my investigations strptime() seemed to simply ignore the second output arg. But OTOH I might have put the pertinent lines there just to be sure. Some years ago I hit several other issues (related to daylight saving) with strptime (mostly because parts of its output can be "implementation-defined") so yes with those reminiscences I may have had some brute force in mind :-)
But anyway the patched datevec.m works fine on my Windows boxen (where I hit this issue) so indeed that part doesn't seem required.

 Philip Nienhuis <philipnienhuis>
Group Member
Sat 05 Aug 2023 02:16:53 PM UTC, comment #4: 

I pushed your patch with some changes to the stable branch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/23768773e933

Most notable differences to the submitted patch:

  • All the new formats are ones that are standardized in ISO 8601. So, I referred to them as "ISO 8601 conform" instead of "contemporary".
  • It shouldn't be possible for a variable to be undefined after it was used on the left-hand-side of an assignment. So, I removed that part of the changes. If that should ever happen, it is a different bug that should be addressed elsewhere specifically.



Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Tue 01 Aug 2023 07:16:04 PM UTC, comment #3: 

These patches weren't primarily meant to fix existing compatibility problems with Matlab (nice that they do, however) but rather to extend datevec.m's capabilities.

The new date formats in the patch occur regularly in files and downloads created by newer SW and several publicly accessible databases. Extending Octave's capabilities beyond those of Matlab (as long as it lasts) isn't necessarily a bad thing.

 Philip Nienhuis <philipnienhuis>
Group Member
Sat 29 Jul 2023 01:17:33 PM UTC, comment #2: 

Fwiw, in Matlab R2023a:

>> datevec ("1998-07")

ans =

        1998           7           1           0           0           0

>> datevec ("1998")
Error using datevec
Cannot parse date 1998.

>> datevec ("1998-07-19T15:03:47Z")
Error using datevec
Failed to lookup month of year.

>> datevec ("1998-07-19T15:03:47.219Z")
Error using datevec
Failed to lookup month of year.


And Octave 8.2.0:

>> datevec ("1998-07")
error: datevec: none of the standard formats match the DATE string
error: called from
    datevec at line 139 column 11
>> datevec ("1998")
error: datevec: none of the standard formats match the DATE string
error: called from
    datevec at line 139 column 11
>> datevec ("1998-07-19T15:03:47Z")
error: datevec: none of the standard formats match the DATE string
error: called from
    datevec at line 139 column 11
>> datevec ("1998-07-19T15:03:47.219Z")
error: datevec: none of the standard formats match the DATE string
error: called from
    datevec at line 139 column 11


So, at least the first format `"yyyy-mm"` should be supported for compatibility.

 Markus Mützel <mmuetzel>
Group administrator
Thu 18 May 2023 09:39:42 PM UTC, comment #1: 

New & updated patch attached relative to 6b2c8eae147e

I used to hit failing BISTs since some time. After some searching I found that to be due to strptime apparently returning undefined 2nd arg 'nc' in some cases. Fix for it included.

(file #54762)

 Philip Nienhuis <philipnienhuis>
Group Member
Tue 04 Aug 2020 07:06:08 PM UTC, original submission:  

Fixing bug #58701 and bug #58854 involved, a.o. others, catering for various date-time formats that I've seen quite regularly these days but aren't yet in datevec's collection.
I saw several of these formats in Google files (.gpx, .kml) and in LibreOffice (.ods) and Excel (.xlsx).

So I think it would be useful to add these date-time formats so that datenum.m can more easily parse cellstr vectors containing a mix of date-time strings with varying formats (or better said: ...so that user have less issues feeding such datetime string vectors to datenum.m).

 Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #54762:  patch_9964_datevec_add_formats_v2.cset added by philipnienhuis (3KiB - application/octet-stream)
file #49629:  datevec_add_formats.cset added by philipnienhuis (891B - 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 mmuetzel (Posted a comment)
  • -email is unavailable- added by philipnienhuis (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 logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-05 mmuetzel StatusNone Ready For Test
    2023-05-18 philipnienhuis Attached File- Added patch_9964_datevec_add_formats_v2.cset, #54762
    2020-08-04 philipnienhuis Attached File- Added datevec_add_formats.cset, #49629

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-c8cf.
    Corresponding source code