timestamp notation @gnupg.org

[Jerome Baum]

>>> Aren't the timestamps recorded in the signature
>>> packets as unix time [1], and displayed in the local
>>> time detected from the user's system?
>
>> I was referring to the interval notation.
>
> I see. I'm not sure how the interval notation will interact with the
> timestamp. If "behind the scenes" the interval were actually recorded
> as seconds (and the timestamp is recorded as seconds since epoch),
> then it is automatically anchored to UTC. But, as at present, does not
> have to be displayed in UTC.

Why are we even talking about ISO 8601? Because I suggested it as a
format to record the data. Not seconds since epoch, twice; ISO 8601
interval, and be done.

Local display is something entirely different:

1. Protocol on the one hand (needs to be unambiguous); and

2. Local interaction on the other hand (can be local timezone, UTC,
another timezone, who cares?).

>> Except, what is "local time" if you have two people in
>> different timezones?
>
> Local time to each person is the time in their respective timezone.

The point is, if there's no timezone noted down in the interval, there
is no way to know what the timezone was when the person made the
signature. We're talking about data at rest, that could be interpreted
many years later, and it'll be difficult to "guess" the timezone then.
Plus, it shouldn't be a guess anyway.

>> That's why we'd need either the
>> "all times UTC" rule, or a forced timezone in the
>> field.
>
> I think we do not need it.
>
> What is wrong with your system displaying that a signature was made
> 20110618T000000/P1D (your local time) and my system showing that the
> same signature was made 20110617T230000/P1D (my local time)? That's
> what happens now (with exact times rather than intervals) and I have
> seen no discussions of ambiguity or the need to state timezones.

Ah, but now we're talking display. I was talking about the content of
the notation. Display can be however an implementation chooses to
display this (raw notation value if I just use current gnupg with
show-notations), but that isn't really a question here. What's more
important is how an implementation constructs the interval, and how
another de-constructs/parses it.

> What I was trying to impart was that when I see a time, I interpret it
> to be a time stated in my local time unless I am aware of a reason to
> think otherwise. So when I see 20110617T230000/P1D, in the absence of
> any information to the contrary, I understand it as local time which
> (in the Summer) is 20110617T230000+0100/P1D.
>
> It seems likely to me that somebody in a +0200 time zone would
> similarly assume a time to be in their local time zone, so would
> interpret 20110618T000000/P1D to mean 20110618T000000+0200/P1D.

Right. So discussing your actual point (after we've resolved that we
were talking about different things/"past each other"), I would say
local timezone is fine for display. I would say, let the user choose,
give them a configuration option.

>> That isn't what I was referring to. 20110618T000000/P1D
>> is ambiguous: Is it 20110618T000000+0200/P1D or
>> 20110618T000000+0100/P1D ?
>
> GnuPG stores the timestamp in seconds since epoch and displays it in
> the local time detected from the machine it is running on. AFAIK, we
> were not suggesting this changed.
>
> If the signature was created on a machine with local time zone set to
> +0200, then it means 20110618T000000+0200/P1D. If somebody views that
> signature on a machine with local time zone set to +0100, then they
> will see 20110617T230000/P1D, which means 20110617T230000+0100/P1D and
> refers to the same interval as 20110618T000000+0200/P1D.

Right. Local display vs. recording. I'll just summarize again:

1. Interval is recorded as an ISO 8601 interval, and must be
unambiguous (i.e. contain a proper timezone for each timestamp).

2. OpenPGP's timestamp is not changed (seconds since epoch UTC).

3. Local display, of both the timestamp and interval, is out of the
question for now. However, I would suggest some option to let the user
configure it. It's up to each implementation anyway.

In terms of moving forward, I think the ISO 8601 ambiguity of lower
precision in an interval is something we need to resolve. Since we're
introducing the interval to allow for lower precision (e.g. round to
the start of the day), I think the interval itself should have full
precision. We would interpret any dropped components as zeros/ones
resp. ("01" for months/days, "00" for hours, minutes, seconds,
fractional seconds).

Looking at this practically, say I round down to the start of the day.
Clock drift isn't really an argument for an imprecise interval,
because "2010Z" still means "at or after 2010-01-01T00:00:00Z", but
clock drift could have me signing this on 2009-12-31Z. So in short,
clock drift, the thing that would be the most likely concern, isn't a
problem of precision (clock still resolves down to (nano-)seconds),
but of accuracy. Less precise intervals cannot solve that, bigger
intervals can.

So here's the new suggested spec:

1. timestamp-only at gnupg.org. Let's omit this part for the sake of a
friendly discussion.

2. Suggestion: timestamp-interval at gnupg.org. Value is an ISO 8601 time
interval during which the timestamp was made, leaving no room for
interpretation of the interval, but making it the signer's duty to
compute this interval.

2 a. Non-critical.

2 b. Must have a timezone associated for each timestamp. "Z", "+0100",
etc. As a safe-guard for broken implementations, should we assume an
implied "Z" if there is no timezone?

2 c. Local display/interaction is something the implementations will
sort out. We recommend at least the obvious "canonical" options of
local timezone and UTC display. Practically, after parsing the
interval into two timestamps, handling would be similar to the OpenPGP
timestamp field (except that isn't enriched with the timezone, which
you could use to enhance the output). Often enough, this boils down to
"whatever the locale is configured to do" and that sounds in line with
*NIX philosophy.

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