CESNET
[date-and-time]Is there a problem with the parse function?
DATA in mem:
<signature-database-update-state xmlns="urn:huawei:params:xml:ns:yang:huawei-signature-database-update">
<result>
<signature-database-type>intrusion-prevention</signature-database-type>
<result>fail</result>
<result-description>fail</result-description>
<result-code>2232681065</result-code>
</result>
<result>
<signature-database-type>application</signature-database-type>
<result>fail</result>
<result-description>fail</result-description>
<result-code>2233205344</result-code>
</result>
<result>
<signature-database-type>cnc</signature-database-type>
<result>fail</result>
<result-description>fail</result-description>
<result-code>2232681065</result-code>
</result>
<state>
<signature-database-type>intrusion-prevention</signature-database-type>
<current-version>
<version>2019102308</version>
<size>455536</size>
<update-time>2023-10-10T04:00:36+00:00</update-time>
<issue-time>2019-10-23T18:47:40+00:00</issue-time>
</current-version>
<backup-version>
<version/>
<size>0</size>
<update-time>0000-00-00T00:00:00+00:00</update-time>
<issue-time>0000-00-00T00:00:00+00:00</issue-time>
</backup-version>
<download-version>
<version/>
<size>0</size>
</download-version>
</state>
<state>
<signature-database-type>application</signature-database-type>
<current-version><version>2023062700</version>
<size>3925775</size>
<update-time>2023-10-10T04:00:36+00:00</update-time>
<issue-time>2023-06-25T10:28:28+00:00</issue-time>
</current-version>
<backup-version>
<version>2023042000</version>
<size>3902253</size>
<update-time>2023-07-19T10:19:57+00:00</update-time>
<issue-time>2023-04-20T18:20:05+00:00</issue-time>
</backup-version>
<download-version>
<version/>
<size>0</size>
</download-version>
</state>
<state>
<signature-database-type>cnc</signature-database-type>
<current-version><version/>
<size>0</size>
<update-time>0000-00-00T00:00:00+00:00</update-time>
<issue-time>0000-00-00T00:00:00+00:00</issue-time>
</current-version>
<backup-version>
<version/>
<size>0</size>
<update-time>0000-00-00T00:00:00+00:00</update-time>
<issue-time>0000-00-00T00:00:00+00:00</issue-time>
</backup-version>
<download-version>
<version/>
<size>0</size>
</download-version>
</state>
</signature-database-update-state>
a part of MODULE:
grouping version-information {
leaf version {
type string;
description "The version of signature database.";
}
leaf size {
type uint32;
units byte;
description "The size of signature database.";
}
leaf update-time {
type yang:date-and-time;
description "The update time of signature database.";
}
leaf issue-time {
type yang:date-and-time;
description "The issue time of signature database.";
}
}
when i call lyd_parse_data_mem() LYD_XML , LYD_PARSE_ONLY, LYD_VALIDATE_PRESENT
show error:
/backup-version/update-time", line number 1.:Unsatisfied pattern - "-001-11-30T00:00:00+00:00" does not conform to "\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(.\d+)?(Z|[+-]\d{2}:\d{2})".
Is there a problem with the parse function?
Thanks!
The example is trying to construct a yang:date-and-time out of a value 0000-00-00T00:00:00+00:00. To a human, this value is probably meant to represent an unknown date and time, but that's not actually the case here because the value actually means, literally, "day 0 of month 0, year 0, midnight, UTC timezone". Since it has an explicit TZ, libyang attempts to convert this into your local timezone, and that yields a negative year.
I would say that the input data are garbage ("what exactly is month 0 and day 0?"), but it can also be argued that libyang mishandles this garbage input by producing more garbage. But if we were to language-lawyer here, this is technically a negative year which is explicitly forbidden by the RFC :).
I suppose a proper error message can be displayed instead but it makes little difference, negative years are simply not supported. Easy fix would be using -00:00 timezone instead.
Value 0000-00-00T00:00:00+00:00 obviously does not represent actual timestamp so I am not sure what you are asking. Timezone -00:00 is a special one that is not being transformed based on the local timezone of the machine so it should stay exactly as is in the input.
The time zone of the computer running this test case is set to 0 time zone.
date -R
Mon, 09 Oct 2023 21:59:44 +0000
How exactly is your system setup? What architecture is it (x86_64, x86 32bit, ARM, and if so, which one, etc), what C library do you use (glibc/musl/..., and which version), and how does your /etc/localtime and the TZ environment variable look like?
Since +00:00 is a valid TZ in YANG's date-and-time, libyang won't treat it as "unknown TZ", and that also means that it will consider the system's current DST settings when it produces the canonical format. That's all as per the RFC.
x86_64 and libyang is 32bit, GLIBC_2.34
cat /etc/localtime
TZif2UTCTZif2UTC
UTC0
echo $TZ
date
Tue Oct 10 10:12:15 UTC 2023
I have actually tried this and the problem is quite obvious now. The date-and-time value is not valid, neither day 0 nor month 0. That is what libyang (mktime()) is trying to adjust for. But the current libyang version checks for this and will not even allow you to store such an invalid value.