Project

Profile

Help

Bug #6377

closed

format-time on Unix throws DateTimeException if "[Z]" pattern is used

Added by Nico Kutscherauer 9 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2024-03-23
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
11, 12, trunk
Fix Committed on Branch:
11, 12, trunk
Fixed in Maintenance Release:
Platforms:
Java

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 for format-date() or format-dateTime().

You can find reproductions of the issue on this GitHub project:

https://github.com/nkutsche/saxon-he-issues/actions/workflows/maven.yml

Actions #1

Updated by Michael Kay 9 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.

Actions #2

Updated by Michael Kay 9 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).

Actions #3

Updated by Michael Kay 9 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
Actions #4

Updated by O'Neil Delpratt 6 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

Also available in: Atom PDF