Project

Profile

Help

Support #5608

closed

Strange behavior when trying to get the current date.

Added by fouad MOUTASSIM almost 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT 3.0 packages
Sprint/Milestone:
Start date:
2022-07-15
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:
Java

Description

Hello,

we have a strange behavior when trying to get the current date using an XSLT map(The used function is : current-date()). we get a random result. Sometimes we get the correct date and sometimes we get the current date minus days.

Exp : <xsl:value-of select="concat(format-date(current-date(), "[Y0001]-[M01]-[D01]")," 08:45")"/>

Result 1 [OK] >> 2022-07-15 08:45

Result 2 [KO] >> 2022-07-12 08:45

Could you please provide us an explanation for this behavior.

bellow the used configuration :

Saxon : Saxon-EE-10.4-1 Java : version 11 OS : openjdk-11

Thank you in advance.


Files

currentDateIssue.xslt (74.4 KB) currentDateIssue.xslt Anis MILED, 2022-07-21 17:03
fwkMappingIn.xml (767 KB) fwkMappingIn.xml Anis MILED, 2022-07-21 17:35
csv-xsl-package.xslt (5.45 KB) csv-xsl-package.xslt fouad MOUTASSIM, 2022-07-22 15:37
Xslt30CacheServiceImpl.java (3.22 KB) Xslt30CacheServiceImpl.java fouad MOUTASSIM, 2022-07-22 15:37
Xslt30TransfoServiceImpl.java (5.31 KB) Xslt30TransfoServiceImpl.java fouad MOUTASSIM, 2022-07-22 15:37
Actions #1

Updated by Michael Kay almost 2 years ago

I'm sorry, I have never seen this effect and I have no idea what might be causing it. We're very unlikely to be able to find the cause unless you can show us the code that is exhibiting this effect, in such a way that we can reproduce it; or at the very least, to tell us a lot more about the operational conditions.

For a start, how are you running the transformation? From the command line, or from an API? If so, which API? Are you using some framework such as Spring? Do you compile a stylesheet once and then execute it repeatedly, and if so, how do you organise this?

Saxon obtains the current date and time from the operating system (via the JDK), so there could be an issue with the external dependencies used here. What operating system are you using? is it a cloud environment? Saxon only requests the data and time once for any given transformation. Are your transformations long-running?

Can you reproduce the effect by making direct calls to the JDK? Does saxon:timestamp() show the same anomalies (saxon:timestamp differs from current-dateTime() in that it delivers a different result each time it is called, whereas current-dateTime is constant for the duration of a transformation).

Hopefully this gives you some possible lines of investigation.

Actions #2

Updated by Michael Kay almost 2 years ago

  • Status changed from New to AwaitingInfo
Actions #3

Updated by fouad MOUTASSIM almost 2 years ago

Hi,

here are some responses to your questions.

we are using containers on kubernetes cluster in azure cloud . and the applications were made with spring-boot. OS : Debian GNU/Linux 11 (bullseye) JAVA : 11

We compile the stylesheet once , put it in a local cache and run it repeatedly.

We continue to investigate on our side as well.

Thank you.

Actions #4

Updated by Michael Kay almost 2 years ago

When you run the stylesheet repeatedly, do you create a new Transformer object (from the cached Templates object) each time, or do you reuse the same Transformer.

In Saxon we recommend creating a new Transformer each time.

I believe that the current date and time is only set once for a given Transformer. It doesn't appear to be reset even if you call reset() on the JAXP Transformer object. We should probably change that. I would certainly recommend creating a new Transformer (using Templates.newTransformer()) for each transformation if you can, but perhaps it's not possible when everything is under Spring's control.

Actions #5

Updated by Michael Kay almost 2 years ago

Correction: I think that if you reuse a JAXP Transformer, then if you call Transformer.reset(), the date and time will be reset, but if you don't call reset(), they probably won't.

Actions #6

Updated by fouad MOUTASSIM almost 2 years ago

Thank you for your reply.

We are using a new transformer each time.

Actions #7

Updated by Anis MILED almost 2 years ago

We find out a workaround, when we use a variable, and we store in it the current-Date, and we use the variable later in the xslt, it works fine. When use the function more then one time, the issue occurs

Actions #8

Updated by Michael Kay almost 2 years ago

Can you supply a repro that we can execute "in the lab" to reproduce the bug and track it down? That's the only way we are going to get to the bottom of this.

Actions #9

Updated by Anis MILED almost 2 years ago

you will find attached the xslt file

Actions #10

Updated by Michael Kay almost 2 years ago

Thanks for the XSLT file. We also need to know how you are running it so we can reproduce the steps: from the command line or from a Java application, with what source document and what parameter values. It's also useful to know what we are looking for in the result that indicates the results are wrong.

I notice that the XSLT file uses XSLT 3.0 packages, which could well be a pertinent factor. We'll need a copy of all packages and modules used.

Actions #11

Updated by Anis MILED almost 2 years ago

We are running it from a java application, We have a monitoring tool, and we saw in it that the xslt was executed today for example, but the field sendDate has a two days ago date.

i attached the source document. We are not using any specific parameters

Actions #13

Updated by Michael Kay almost 2 years ago

Could you please supply (a) the code of hte package csv-xsl-package, and (b) the Java code you are using to run the transformation?

Actions #15

Updated by Michael Kay almost 2 years ago

Thanks. You do seem to be caching the Xslt30Transformer, rather than the XsltExecutable.

Serial reuse of an Xslt30Transformer is permitted, though not encouraged: see the documentation at https://www.saxonica.com/documentation11/index.html#!javadoc/net.sf.saxon.s9api/Xslt30Transformer (Note especially that concurrent use of an Xslt30Transformer in multiple threads is unsafe; your caching code appears to do nothing to prevent this happening.)

I will update the documentation to point out that the current date and time remains constant for a given Xslt30Transformer instance.

It looks as if changing your code to cache the XsltExecutable will be very straightforward.

Actions #16

Updated by fouad MOUTASSIM almost 2 years ago

Thank you.

We will try your suggested solution and keep you informed.

Actions #17

Updated by Michael Kay over 1 year ago

  • Tracker changed from Bug to Support
  • Status changed from AwaitingInfo to Closed
  • Priority changed from High to Normal

Closed with no further action. The problem was a user error (reusing the Xslt30Transformer).

The Javadoc documentation is already clear that when an XsltTransformer or Xslt30Transformer is serially reused, the current date and time is not reset for each transformation.

Please register to edit this issue

Also available in: Atom PDF