timestamp notation @gnupg.org

[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.

See http://tech.groups.yahoo.com/group/ISO8601/message/226 for details
(be sure to look at the other replies as well). I don't have ISO 8601
handy, so I can't speak first hand. However, this example seems very
rational:

"The 20th Century
1901-01-01 / P100Y
1901-01-01 T 00:00:00 / 2001-01-01 T 00:00:00"

>> 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?

Yes. I'm purposely leaving out the whole timestamp-only discussion.

>> 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.).

Exactly. This would be an implementation choice. I think a good first
start for gnupg would be a parameter to specify a fake timestamp. The
notation is already possible. Then it's easy to write a command-line
wrapper for custom stuff, or even just specify a fixed notation and
fixed fake timestamp ("1970/P68Y" with timestamp 0).

> What about a user who desired no datestamp at all? Would they just use
> something like 1970-01-01T00:00:00/P68Y?

Not sure. Personally I'd use P200Y. Nice "pun" there, btw. :)

> 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.

Ah, we've been careless. Append a "Z" to your dates and they are UTC
(or append a timezone, if you want that). Those two intervals are
actually ambiguous AFAIK. We could specify either:

1. All times must be UTC ("Z") or have a timezone; or

2. Ambiguous times are interpreted as UTC.

-- 
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA