This document describes how time is organised in XML-X.
This is not a reference document, nor a draft for a standard. For such documents, see the XML-X site.
The purpose of XML-X is to enable clients to deliver accounts and payment instructions to servers.
Time is a special problem. Different needs use different representations of time. Conversions that are accurate are needed between all of the representations.
The problems of time are especially acute with financial transactions. XML-X delivers receipts that could be considered in a court of law. Disputes over payments cannot be eliminated with mere code. But, and they can be simplified, and incompatibilities such as those found in other formats can be minimised [1]. XML-X has a responsibility to all developers and operators to make the data as clear and as accurate and as unambiguous as possible.
The mission of this project is
to create a protocol for spend interfaces and front-end/back-end interfaces that can be the standard for all web based accounting systems.
Within the above context, one suitable time base is chosen for all time representations: win32.
A <Time> includes the win32 time.
<Time> 123456789012345678 </Time>
win32 time is an 18 digit integer.
Aliases include <From> and <Till>. These are time range limits for a <HistoryRequest>.
XMLXTime number of 100-nanosecond intervals that have passed since 00:00 01 January 1601 UTC. This time is called the win32 epoch.
NOTE that Unix time is only capable of representing dates between Unix epoch, 01 January 1970 and when it runs out of 31 bits and goes negative, 19 January 2038. If an XMLXTime is out of this range, and is converted into Unix time (or Java Time) junk will result.
Therefore, only an XML-X time that can convert to Unix time is a legal time. That is, it should be greater than the difference between the epochs, and less than some number that translates to 19 Jan 2038. (in seconds, 2147483648).
To be safe, only produce example times that are closer to the current time. This problem will go away when Unix has finished converting to 64 bit time (an ongoing project that will take a few years).
This section documents the magic numbers.
Both epochs are Gregorian. Unix is 1970 and win32 is 1601 so 369 is the number of years (1970 - 1601 = 369).
Assuming a leap year every four years gives 92 leap years (369 / 4 = 92). However, 1700, 1800, and 1900 were NOT leap years, which leaves us with 89 leap years and 280 non-leap years.
Calculate the number of days, thus:
89 * 366 + 280 * 365 = 134744 days between epochs. Of course 60 * 60 * 24 = 86400 seconds per day, so 134744 * 86400 = 11644473600 = SECS_BETWEEN_EPOCHS.
This result is also confirmed in the MSDN documentation on how to convert a time_t value to a win32 FILETIME.
These notes taken from here.
A special problem occurs with machines that only deal with 32 bit integers. Due to the size of the time base, only 64 bit integers can hold it, in general.
In order to convert to Unix time, do this:
The last two steps can be done as strings instead of integers. In this way, the same process can create Java time, by adding a string of 5 leading digits from the low-order string, which adds the milliseconds.
Motives for the choice of time base are discussed in this section.
Subject: [xml-api] Time: win32 / 100ns / 1601
Date: Fri, 04 Oct 2002 00:14:08 -0400
From: IanG <iang@systemics.com>
To: XML API <xml-api@intertrader.com>
I'd like to propose that the time base for XML-X be
the same as win32. This is 100ns ticks since 1601.
It's 64 bit time. Reason for this is that it gives
100ns resolution to transactions. Now, that might
seem ludicrously fine, but, on a modern processor,
which does 2GHz, it has 200 clock cycles to do a
transaction. That isn't as much headway as might
be needed in say 10 years time.
I don't know what serious efforts advertise in TPS
these days, but it's in the '000 per second. Which
puts Java time out of the running, as it is only
resolved to millisecond time. Unix time of course
is left back in the stone age.
I'd also propose that <Date> be changed to <Time>.
That's what all the programmers talk about, and it
is more about what we are dealing with. Date sort
of implies a day resolution, which is ok for banking,
but not good enough for the XML-X community :-)
Any objections / comments / improvements / other
views?
It would look something like this:
<Time> 12345678901234567 </Time>
It's an 18 digit number. Oh, as a detail, anything
that doesn't fit in Unix time would be illegal, until
Unix converts to 64bit time (sometime in the next
decade, they've got until 2038).
Same might or might not apply to History... I've not
got to that. I'm working my way through a set of
Java XML-X classes, and am still on the non-request
classes.
--
iang
Subject: Re: [xml-api] Time: win32 / 100ns / 1601
Date: 05 Oct 2002 18:21:00 +0100
From: Pelle Braendgaard <pelle@neubia.com>
To: xmlx <xml-api@intertrader.com>
I think the best approach is to stick with the ISO 8601 representation
recommended in the XML-Schema definition at:
http://www.w3.org/TR/xmlschema-2/#dateTime
and here:
http://www.w3.org/TR/NOTE-datetime
It is not based on the Millisecond since whenever scheme, but is a
relatively easy to read and parse date time specification with an
optional subsecond resolution.
The Java library I use for this in NeuDist has this to say about it:
http://www.opensymphony.com/oscore/utility.html#DateUtil
As an example I've got the following attribute in a signed object
(packet/element whatever) within NeuDist:
<XXXX nsdl:name="neu://test/hello"
nsdl:timestamp="20021005T121423802GMT+00:00"/>
Subject: [xml-api] 8601 considered bad by majority of computers...
Date: Tue, 08 Oct 2002 16:12:41 -0400
From: IanG <iang@systemics.com>
To: XML API <xml-api@intertrader.com>
Erwin and Pelle have suggested ISO 8601 as a timebase,
and I just posted a link from Pelle in full, as a BDG
for quick uptime. ISO 8601 seems to be the timebase of
preference for the XML people, so we have to look closely
at it.
(Jeroen proposed win32 time. I concurred with Jeroen,
and wrote it up a week or so back. I was thinking Unix
time, then Java time, but win32 beats them both on points.)
Here's my analysis of ISO 8601 and why I think it is
inappropriate for XML-X. I'm looking forward to some
aggressive replies :-)
ISO 8601 is an attempt to standardise forms of *written*
dates and times, expressions that humans can deal with.
In that sense, it's quite laudible, most humans I have met
need all the help they can get (I include myself in that
category).
We are dealing here with something else. We are dealing
with computers. Computers are different to humans, they
have better parts and worse parts. Different is a good
word, not better nor worse.
Computers like precision. They like solidity, and they
despise ambiguity.
ISO 8601 is everything that a computer hates. There is
no mandated precision, and a whole bunch of ways in which
it can vary. Great for humans, sucks for computers.
Your mere computer is going to go nuts trying to decide
whether a year is an appropriate way to describe the date
of a transaction. Humans will be asked for arbitrary
rulings on it, which means implementations will differ,
and programmers will ignore the arbitrary rulings, and
computers will go nuts.
Even when we turn around and "require" second resolution,
we find multiple ways of specifying that. Multiple
separators, choices of Timezones, and two ways of saying
goodnight (00:00, 24:00). Leap years, and .. oh yummy,
those evil leap seconds wait in lurk for the naive computer.
Much ink will be spilt - check those links - in 'fixing'
the representation for computers. They missed the point,
it's broken and wrong.
And, I'm a bit surprised at the XML standards people at
pushing this, I though the idea of XML was to make it
easy to push data, not hard. The whole point of XML,
in my ignorant mind, was to reduce everything to
<year>1995</year>
<month>12</month>
...
strings, so computers could deal with it.
Unix solved the time problem back in 1970. Keep seconds
for the computer. If a human wants to look at the time,
then the software will convert that to a human's view.
Software is there to make humans' lives easier, not to
make computers' lives hard. (Win32 time is just a slightly
better form of Unix time, is all.)
Recall, XML-X packets are never meant to be read by humans.
All uses of XML-X are from program to program.
With XML-X it is even more severe than this (providing
the exception *and* the rule). XML-X deals in transactions,
which means money, which means court cases. Ever spent
time with a lawyer? It sucks your soul and it slows your
code.
Our job is to reduce dispute (court) time by delivering
the most unambiguous time there is. I don't want to stand
up in court and explain what year 19991231T240000EDT-0500
is in and what this means to the legal position ...
iang,
who, in another time, even worked on the ISO standards
body for OSI, but doesn't admit to which timebase....
Links posted by Pelle:
http://www.cl.cam.ac.uk/~mgk25/iso-time.html#time
http://www.w3.org/TR/NOTE-datetime
http://www.w3.org/TR/xmlschema-2/#isoformats
Subject: Re: [xml-api] Time: win32 / 100ns / 1601
Date: Fri, 04 Oct 2002 12:39:29 -0400
From: IanG <iang@systemics.com>
To: xml-api@intertrader.com
IanG wrote:
>
> I'd like to propose that the time base for XML-X be
> the same as win32. This is 100ns ticks since 1601.
An alternate to this is to permit *any* or *many* time
bases.
For example, it is possible to accept win32, Unix and
Java time, and deal with them on inspection. That is,
they are all defined number ranges, with Unix being
10 digits, Java 13, and win32 being 18.
The question is, what is easiest for the developer?
After some thought, it is the easiest, IMHO, if the
most accurate time base is used, and the weaker ones
are converted locally. The reason for this is that
there then only O(n) complications; that is, a conversion
into the timebase, then a conversion out of the time base,
so it ends up being 2(n-1) conversions and paths to code
up.
Alternately, we end up with an n-squared problem. So,
if we have 10 code bases, then we have to deal with a
conversion from each to each.
Hence, the task became to identify a convenient one
that was most accurate, and also easy to convert to.
I admit to be interested to see if XML followed the
same logic!
PS: Oh, and I think I forgot to mention, that the
timebase should be in UTC. It's the whole net, after
all.
--
iang
The Primary Authors of XML-X are Erwin van der Koogh and Ian Grigg. The Author of this document is Ian Grigg, with contributions from all the above. See Contributors for more influences.