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.001S')}ms </xsl:message>(Saxon's optimizer will pre-evaluate the constant expressions at compile time, so these do not add run-time overhead.)