mark@cbosgd.UUCP (Mark Horton) (04/22/86)
We have an application which involves passing dates/times over
an X.410/X.409 based network protocol. We're interested in having
our date/time format be as standard as possible, although it's not
currently clear what such conformance will buy us in the long run,
since it is our specific application protocol. (Any thoughts on
that would be welcome.)
Our application needs some extensions to the ISO date/time standards
(2014, 3307, and 4031 are the relevant ISO standards, covering, respectively,
dates, times, and time zones.) A vanilla sample date/time in this format
would be
YYYYMMDDhhmmss-hhmm
19820421132730-0500
or, in UTC (e.g. GMT)
YYYYMMDDhhmmssZ
19820421182730Z
which means April 21, 1982, 1:27:30 PM, EST. We have to be able to include
various amounts of precision and uncertainty in the times. We also want our
dates/times to sort properly using strcmp or a similarly fast routine.
So we want to put everything in GMT.
I have some questions about our interpretation of ISO date/time strings.
(1) Is a string like 1982 (precision = 1 year) or 198204 (1 month) or
1982042113 (1 hour) reasonable?
(2) Can we reasonably put a Z (for UTC) on the end of everything, even
dates, e.g. 1982Z or 19820421Z?
(3) We want to put an E on the end of exact times, to get them to sort
properly with "before" and "after" times, so all our timestamps would
look like 19820421182730ZE. To what extent will this hurt our ISO
compatibility? What do other pieces of software do if they encounter
an extra E on the end of a date/time string? In UNIX, I would think
the likely answer would be "ignore it", but I have no idea what is
likely on other systems.
Thanks in advance,
Mark Horton