#1721 unable to parse ISO string time in attributes
I have an hdf5 where time is given as ISO strings in the format 2014-07-21T22:13:43. The data plots fine but the console says unable to parse the time from the metadata.
unable to parse 0000-00-00T00:00:00
unable to parse 2014-07-21T22:13:43
unable to parse 2014-07-21T15:38:38
unable to parse 2100-01-01T00:00:00
unable to parse 1957-10-04T19:28:00
These are values in the attributres VALID_MIN, VALID_MAX, FILLVAL, SCALEMIN, and SCALEMAX.
In [8]: d['Time']['ISO'].attrs
Out[8]:
{u'CATDESC': 'ZDG Time in ISO',
u'FIELDNAM': 'ISO',
u'FILLVAL': '0000-00-00T00:00:00',
u'FORMAT': '',
u'SCALEMAX': '2014-07-21T22:13:43',
u'SCALEMIN': '2014-07-21T15:38:38',
u'SI_CONVERSION': '',
u'UNITS': '',
u'VALIDMAX': '2100-01-01T00:00:00',
u'VALIDMIN': '1957-10-04T19:28:00',
u'VAR_NOTES': 'ISO time for ZDG.',
u'VAR_TYPE': 'support_data'}
More details on my autoplot:
Run from the OSX release.
Build Information:
release tag: v2016a_9
build url: http://apps-pw.physics.uiowa.edu/hudson/job/autoplot-release/3425/
build time: 2016-11-23T14:39Z
autoplot.jar: [1] VirboAutoplot (2016-11-23T14:39Z )
[1] https://svn.code.sf.net/p/autoplot/code/autoplot/trunk/
Runtime Information:
Java version: 1.8.0_102
max memory (MB): 6372.0 (memory available to process)
total memory (MB): 3151.0 (amount allocated to the process)
free memory (MB): 2725.0 (amount available before more must be allocated)
native memory limit (MB): 6372.0 (amount of native memory available to the process)
arch: x86_64
64 bit Java (recommended)
hostname: rbsp4.lanl.gov
pid: 19081
pwd: /Applications/Autoplot.app/Contents/Resources
Seems like that should work. If there are 2-D arrays of characters, and each element is between 14 and 35 characters long, it will try to parse them as times. Can you provide the file?
Here is a file with: (in the attributes)
unable to parse 2098-01-01T00:00:00
unable to parse 2002-01-21T22:13:43
unable to parse 2002-03-21T15:38:38
Last edit: Brian Larsen 2016-11-30
It's in the code that reads in the ISTP metadata, where it looks like it is assuming that a validmin/validmax is doing to be a double. I'll try to figure out why it is incorrectly parsing it later today.
I need to verify that this was fixed. (Brian, sorry if this was never fixed!)