timestamp notation @gnupg.org
expires2011 at ymail.com
Sat Jun 18 18:02:00 CEST 2011
-----BEGIN PGP SIGNED MESSAGE-----
On Saturday 18 June 2011 at 1:29:29 PM, in
<mid:BANLkTi=eYf9Z6S2SOKTp_V2=ocogPv_+KA at mail.gmail.com>, Jerome Baum
> Right. Which is why I wrote "2011-06-17 00:00:00" --
> there are multiple interpretations of "2011-06-17", and
> e.g. ISO 8601 takes it to be the instant at the start
> of the day.
Really? The references I have read suggest to me that ISO 8601 takes
YYYY-MM-DD to be a 24-hour period, and YYYY-MM-DDT00:00:00 to be the
second at the start of the day.
> Exactly. I see it as two parts:
> 1. Add a notation for timestamp-interval. This makes
> the protocol more flexible.
And this was the field you said should be non-critical, right?
> 2. Using # 1, we can then change application code to
> make the implementation more flexible. e.g.: Add an
> option to round down to the start of the day and set
> timestamp-interval to "<today>/P1D".
Or to the start of the week(or month or year, etc.)
and use <that date>/P1W (or P1M or P1Y, etc.).
What about a user who desired no datestamp at all? Would they just use
something like 1970-01-01T00:00:00/P68Y?
What about time zones? Lets say person A, signing the document, has a
local time offset of GMT+2 and person B, receiving the document, has a
local time offset of GMT+1. Person A has their app set to round down
to the beginning of the day, which in person B's local time is
23:00:00 on the previous day. I guess person A seeing
20110618T000000/P1D and person B seeing 20110617T230000/P1D is a
non-issue, since the two refer to the same time interval in UTC.
MFPA mailto:expires2011 at ymail.com
Pain is inevitable, but misery is optional.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users