Fix: DateTimeParser trailing timezone designators & Timezone UTC offset cache invalidation

[kozemcak]

Hi all,

After we update poco to new version our applications tests start failing. We identified these issues and fix it. Some of the issues are little specific, so we are interesting what you say about that. Here are quick summary of our changes.

Thanks.

Summary

This MR contains two bug fixes for the Foundation library addressing datetime parsing and timezone handling regressions.

---

Changes

1. fix(Foundation): DateTimeParser: %S consume optional fractional seconds

Parsing ISO 8601 date strings that contain both fractional seconds and a timezone offset (e.g. "2013-10-07T08:23:19.120-04:00") with the format "%Y-%m-%dT%H:%M:%S%z" raises a SyntaxException:

• %S consumes the integer seconds but stops at ., leaving .120-04:00 unconsumed.
• %z (parseTZD) is called next but sees . and returns without consuming anything.
• The trailing-garbage check then raises SyntaxException.

Fix: Extend the %S case to consume and discard an optional fractional-second suffix (. or , followed by one or more digits) immediately after parsing the integer seconds. This mirrors the existing %s behaviour and allows %z to see the timezone designator directly, keeping the trailing-garbage check fully effective for truly invalid input.

---

2. fix(Foundation): Timezone: invalidate utcOffset cache when /etc/localtime changes

The TZInfo UTC offset cache introduced in Poco commit 1850dc16 is only invalidated when the TZ environment variable changes. Since TZ is process-local, system timezone changes via /etc/localtime (symlink update) go undetected, causing Timezone::utcOffset() to return a stale value.

Fix: Extend cacheTZ()/tzChanged() to track the inode and mtime of /etc/localtime via stat(2). Cache is invalidated when either changes.

---

Testing

• Verified ISO 8601 strings with fractional seconds and UTC offsets parse correctly.
• Verified utcOffset() reflects timezone changes after localtime is updated without modifying TZ.

[matejk]

The ASN.1 UTCTime issue (X509Certificate::validFrom()/expiresOn()) is already fixed in #5263 by including the %Z specifier in the format strings on the caller side.

The other example "2013-10-07 08:23:19.120-04:00" is not a valid ISO 8601 datetime -- ISO 8601 requires the T separator between date and time (the 2019 revision removed the earlier allowance to omit it by mutual agreement). POCO's ISO8601_FORMAT correctly requires it.

The real issue is that %S stops at the fractional-second separator, leaving %z unable to reach the timezone. Rather than tolerating trailing garbage after parsing, a better fix is to make %S consume and discard optional fractional seconds:

case 'S':
    it = skipNonDigits(it, end);
    second = parseNumberN(dtStr, it, end, 2);
    if (it != end && (*it == '.' || *it == ','))
    {
        ++it;
        it = skipDigits(it, end);
    }
    break;

This way %z sees the timezone directly and the trailing-garbage check remains fully effective. Could you test this approach?

[kozemcak]

Hi matejk,

Thank you for the answer. Next week I will look at that and I will try your suggestion.

[kozemcak]

Hi @matejk

Thank you for your help. I again retest it with last main and with fix you recemented and all tests pass now.

Still need use commit fix(Foundation): Timezone: invalidate utcOffset cache when /etc/localtime changes which fix last issue in the application, where we check /etc/localtime. Not sure if you like that part.

[matejk]

Two well-described fixes for real bugs — thanks. A few suggestions inline before merge.

[matejk]

Out of scope for this PR, but worth noting as future follow-ups: this detection is effectively a no-op on Android, where the zone is set via the persist.sys.timezone system property rather than /etc/localtime — bionic's tzset() reads the property. The analogous Timezone_WIN32.cpp could grow a similar check by re-querying GetDynamicTimeZoneInformation and comparing TimeZoneKeyName (or watching the HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation registry key).

[matejk]

@kozemcak, I'd include the fixes to Poco 1.15.3 that is planned for release in a week.

Can you take a look at the comments above?

[kozemcak]

Hi @matejk,
Sorry I miss the notification so I miss your comments, I will look at that.