saxon:timestamp

Returns an xs:dateTimeStamp value representing the instant in time at which the function is called.

timestamp() ➔ xs:dateTimeStamp

There are no arguments

Result

xs:dateTimeStamp

Namespace

http://saxon.sf.net/

Notes on the Saxon implementation

Available since Saxon 9.8. Changed in 9.9 to call java.time.ZonedDateTime.now().

Details

The function returns an xs:dateTimeStamp value representing (as far as possible) the instant at which the function is called. This differs from fn:current-dateTime() in that successive calls return different values. This enables the result to be used for performance instrumentation.

The precision of the result depends on the platform. The xs:dateTime implementation (and java.time.ZonedDateTime on which it depends) is capable of representing nanosecond precision, but some platforms only return millisecond precision.

The timezone in the result is the default timezone for the Java platform, which is generally taken from the underlying operating system. This will usually be the same as the value of implicit-timezone(), except that the timezone may change in successive calls as a result of daylight savings time changes.

Saxon attempts to avoid aggressive optimization of calls to this function, so for example a call will not be lifted out of a loop. However, order of execution is not guaranteed, so there may still be surprises. If the result is bound to a variable, for example, the variable may be inlined or lazily evaluated, which means the timestamp will show the time at which the variable is evaluated, not the time at which it is declared.

If the value is to be used for measuring execution time, the following code is suggested:

<xsl:variable name="start" select="saxon:timestamp()" as="xs:dateTimeStamp"/> <!-- force evaluation --> <xsl:if test="$start eq xs:dateTime('1900-01-01T00:00:00')"><x/></xsl:if> <!-- code under test goes here --> <xsl:message expand-text="yes">Execution time: {(saxon:timestamp() - $start) div xs:duration('PT0.001')}ms </xsl:message>

(Saxon's optimizer will pre-evaluate the constant expressions at compile time, so these do not add run-time overhead.)