timestamp notation @gnupg.org

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Saturday 18 June 2011 at 10:50:08 PM, in
<mid:BANLkTikF1GzDt7tVjh7aqwzmYjzXwZJc6Q at mail.gmail.com>, Jerome Baum
wrote:


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

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





>>> 2. Ambiguous times are interpreted as UTC.

>> I think the ISO 8601 standard assumes local time
>> unless otherwise specified. So it makes sense for each
>> person viewing the signature to see the timestamp in
>> their own local time if no time zone information is
>> included.

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


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




>> 20110618T000000+0200/P1D and 20110617T230000+0100/P1D
>> both refer to the same time period without ambiguity.

> Those have timezones. Your (and my) previous examples
> didn't.

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.




>> If people feel there is ambiguity here, maybe this is
>> best dealt with by adding some simple text to the
>> GnuPG output to indicate that times are shown in local
>> time, as per the user's system.

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

- --
Best regards

MFPA                    mailto:expires2011 at ymail.com

Does anybody really read these things?
-----BEGIN PGP SIGNATURE-----

iQE7BAEBCgClBQJN/gxDnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pOqQEAIOG
z/hYg0wwvr30O6SpWtgmMQ/YyRVqpifwIbUdJfhVndtlPoLHR3AswEjTfZXJDEmm
N5d/uBdoLYj+7CFk87pLc5SytLuUYCJv7dv2Nd4NIXnvmEW5MUyQH1KWCf8CjkeA
WzQsEJInWlrlrr/ejKliwS25qrZZqcjEYOpLWTRP
=rpLn
-----END PGP SIGNATURE-----