Maintenance: Planio will be observing a scheduled maintenance window this Tuesday, November 5, 2024 from 03:00 UTC until 06:30 UTC to perform urgent network maintenance in our primary data center. Your Planio account will be unavailable during this maintenance window.
Bug #6377
closedformat-time on Unix throws DateTimeException if "[Z]" pattern is used
100%
Description
Hi,
if you use for instance this:
<xsl:value-of select="format-time(current-time(), '[h01][m01][Z]')"/>
it throws the following stack trace:
java.time.DateTimeException: Invalid ID for ZoneOffset, invalid format:
at java.base/java.time.ZoneOffset.of(ZoneOffset.java:243)
at java.base/java.time.ZoneId.of(ZoneId.java:404)
at java.base/java.time.ZoneId.of(ZoneId.java:358)
at net.sf.saxon.expr.number.NamedTimeZone.olsonZoneOrUtc(NamedTimeZone.java:471)
at net.sf.saxon.expr.number.NamedTimeZone.inSummerTime(NamedTimeZone.java:464)
at net.sf.saxon.functions.FormatDate.formatComponent(FormatDate.java:353)
at net.sf.saxon.functions.FormatDate.formatDate(FormatDate.java:167)
at net.sf.saxon.functions.FormatDate.call(FormatDate.java:833)
at net.sf.saxon.expr.SystemFunctionCall$SystemFunctionCallElaborator.lambda$elaborateForPull$2(SystemFunctionCall.java:613)
at net.sf.saxon.expr.elab.PullElaborator.lambda$elaborateForPush$0(PullElaborator.java:38)
at net.sf.saxon.expr.instruct.ValueOf$ValueOfElaborator.lambda$elaborateForPush$1(ValueOf.java:420)
at net.sf.saxon.expr.instruct.FixedElement$FixedElementElaborator.lambda$elaborateForPush$0(FixedElement.java:640)
at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:247)
at net.sf.saxon.trans.XsltController.callTemplate(XsltController.java:872)
at net.sf.saxon.s9api.Xslt30Transformer.callTemplate(Xslt30Transformer.java:503)
at net.sf.saxon.Transform.processFile(Transform.java:1375)
at net.sf.saxon.Transform.doTransform(Transform.java:879)
at net.sf.saxon.Transform.main(Transform.java:83)
at org.codehaus.mojo.exec.ExecJavaMojo.doMain(ExecJavaMojo.java:385)
at org.codehaus.mojo.exec.ExecJavaMojo.doExec(ExecJavaMojo.java:374)
at org.codehaus.mojo.exec.ExecJavaMojo.lambda$execute$0(ExecJavaMojo.java:296)
at java.base/java.lang.Thread.run(Thread.java:833)
Suprising was that this happens:
- only on unix systems (e.g. on GitHub actions or using the Docker image maven:3.8.3-openjdk-17 ) but not on Windows systems (at least not on my system: Windows 10, OpenJDK 17 or 8)
- only for
format-time()
but not forformat-date()
orformat-dateTime()
.
You can find reproductions of the issue on this GitHub project:
https://github.com/nkutsche/saxon-he-issues/actions/workflows/maven.yml
Updated by Michael Kay 7 months ago
Thanks for reporting it. It is indeed very rare to get exceptions from standard JDK calls that are operating-system specific.
I suspect that it's not so much the fact that it's "Unix" (whatever that means nowadays), but rather the specific system configuration in particular the date/time/timezone settings.
We'll look into it.
Updated by Michael Kay 7 months ago
It looks like this exception can occur if there is a timezone designator (such as "Africa/Abidjan") in Saxon's list of timezones that is not in the operating system's list of timezones. This is of course not something that should cause us to crash. It's not possible to tell from the stacktrace what the offending timezone name is, and it doesn't really matter, we should just catch the exception and carry on.
In fact, ZoneId.of() defines two exceptions: ZoneRulesException
for a timezone name that cannot be found, and DateTimeException
for a zone ID that has an invalid format. We're catching the first, but not the second. I think we simply need to catch both exceptions.
(In fact ZoneRulesException
is a subclass of DateTimeException
, so we only need to catch the latter).
Updated by Michael Kay 7 months ago
- Category set to Internals
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Applies to branch 11, 12, trunk added
- Fix Committed on Branch 11, 12, trunk added
- Platforms Java added
Updated by O'Neil Delpratt 4 months ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.5 added
Bug fix applied in the Saxon 12.5 Maintenance release. Not marking this closed until patched in older releases (i.e 11.x).
Please register to edit this issue