Mailing List Archive

Michael Sobolev wrote:

>I asked Werner a question concerning whether gmtime (3) or localtime (3) should
>be used while displaying the date of key expiry. He asked me to raise the
>question on ML. So here it is.

>When a user creates a key pair, she may specify for how long the key is valid.
>If I understand correctly (but, actually, it does not matter if the method
>different) two values are stored with the key: the date/time of creation and
>the number of days. The question is: how to display all these times? What to
>use gmtime or localtime?

if the time is stored in UTC (which it hopefully is), it doesn't matter.
choose either display. it'll be consistent. or have a user option.
i think display in local time would be preferable to most people but
i could be wrong (hence an option).

raf

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "r" == raf <raf@comdyn.com.au> writes:

r> i think display in local time would be preferable to most people but
r> i could be wrong (hence an option).

I want to support this suggestion: local time is usually a good idea
and should be the default. But having an option to switch to UTC is a
good idea as well.

Bye,
Michael

- --
PGP Key on Servers -- Finger-Print: 51ECA5D2 13938F91 CBF76CC4 F8B5B67C

If God is perfect, why did He create discontinuous functions?

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNgfdMA9NARnYm1I1AQEs9AQAuTZv7/BivK4QC+ZHibwnTlvTK4h/8PQQ
XoTrkRgu+G8W7dLwBvIB41MV75IK5ztPIkvyZCmovWk3/NZGve0n9GJDrrQNO6ff
JWqpwfMo+Fq059dw9hAKtZf7r0yXuFCKe3hXl35Wka6dz7Gl8hoAgIqrqWfKHOUL
M/OIR98fcM8=
=pEN0
-----END PGP SIGNATURE-----

Michael Deindl <olmur@dwarf.bb.bawue.de> writes:

> I want to support this suggestion: local time is usually a good idea
> and should be the default. But having an option to switch to UTC is a

Here is the reason, why I do not like time conversion:

pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
^^^^^^^^^^

This may get listed as -07-08 or -07-06 depending on the timezone.
I think that this could lead to some confusion if two persons list the
key but get different times (yes they are not different really, but it
seems so)

I all other cases a localized time is okay for me.


Werner

On Tue, Sep 22, 1998 at 08:41:38PM +0200, Werner Koch wrote:
> Here is the reason, why I do not like time conversion:
>
> pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
> ^^^^^^^^^^
>
> This may get listed as -07-08 or -07-06 depending on the timezone.
> I think that this could lead to some confusion if two persons list the
> key but get different times (yes they are not different really, but it
> seems so)
>
> I all other cases a localized time is okay for me.

I believe that using mix of gmt and localized times may lead to other
confusions. My vote goes for having an option that control how *all* times
are considered.

--
Mike

On Tue, 22 Sep 1998, Michael Sobolev wrote:

> On Tue, Sep 22, 1998 at 08:41:38PM +0200, Werner Koch wrote:
> > Here is the reason, why I do not like time conversion:
> >
> > pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
> > ^^^^^^^^^^
> >
> > This may get listed as -07-08 or -07-06 depending on the timezone.
> > I think that this could lead to some confusion if two persons list the
> > key but get different times (yes they are not different really, but it
> > seems so)
> >
> > I all other cases a localized time is okay for me.
>
> I believe that using mix of gmt and localized times may lead to other
> confusions. My vote goes for having an option that control how *all* times
> are considered.

I would disagree with your statement that mixing gmt and local time will
cause confusion. What will cause confusion is mixing of semantics. When
you are using a date to represent when something occured in the context of
the person using the software, you ought to use the local time. If you
are using a date that is to identify something external, such as when a
key was created, you should use UTC.

In the above case of a key listing, the same date should appear the same
no matter where the person running the program is. Consistency is really
all that matters in user interface design.

As a general rule I agree that using local time is a good thing as it has
more meaning to the user. Also, I would say that being consistent in
usage of UTC or local time is important as well, however all things must
be considered in the context of how they will be used.

C=)

--------------------------------------------------------------------------
There is hardly a thing in the world that some man can not
make a little worse and sell a little cheaper.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: 1024D/7BBB1485
--------------------------------------------------------------------------
I didn't fight my way to the top of the food chain to be a vegetarian.

On Tue, Sep 22, 1998 at 01:56:00PM -0700, Caskey L. Dickson wrote:
> I would disagree with your statement that mixing gmt and local time will
> cause confusion. What will cause confusion is mixing of semantics. When
> you are using a date to represent when something occured in the context of
> the person using the software, you ought to use the local time. If you
> are using a date that is to identify something external, such as when a
> key was created, you should use UTC.

OK. Could you please provide me with more examples of such "external" events?
At the moment, I can only see only one such an event: key creation; all other
events are always considered in context of the person using the software. As
result, the key creation time should always be displayed using gmtime (3)
function, while all other times -- using localtime (3) or gmtime (3) according
to the specified option.

--
Mike

On Wed, 23 Sep 1998, Michael Sobolev wrote:

> On Tue, Sep 22, 1998 at 01:56:00PM -0700, Caskey L. Dickson wrote:
> > I would disagree with your statement that mixing gmt and local time will
> > cause confusion. What will cause confusion is mixing of semantics. When
> > you are using a date to represent when something occured in the context of
> > the person using the software, you ought to use the local time. If you
> > are using a date that is to identify something external, such as when a
> > key was created, you should use UTC.
>
> OK. Could you please provide me with more examples of such "external"
> events? At the moment, I can only see only one such an event: key
> creation; all other events are always considered in context of the
> person using the software. As result, the key creation time should
> always be displayed using gmtime (3) function, while all other times --
> using localtime (3) or gmtime (3) according to the specified option.

AFAIK there aren't any other examples of external events in gpg. Someone
more familiar with the application would have to compile those.

As for your summation, we are in total agreement.

C=)

--------------------------------------------------------------------------
There is hardly a thing in the world that some man can not
make a little worse and sell a little cheaper.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: 1024D/7BBB1485
--------------------------------------------------------------------------
I didn't fight my way to the top of the food chain to be a vegetarian.

Werner wrote:

>Michael Deindl <olmur@dwarf.bb.bawue.de> writes:

>> I want to support this suggestion: local time is usually a good idea
>> and should be the default. But having an option to switch to UTC is a

>Here is the reason, why I do not like time conversion:

>pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>

>This may get listed as -07-08 or -07-06 depending on the timezone.
>I think that this could lead to some confusion if two persons list the
>key but get different times (yes they are not different really, but it
>seems so)

i don't understand. how can it lead to confusion
if these two people are in different timezones?

raf

Caskey wrote:

>On Tue, 22 Sep 1998, Michael Sobolev wrote:

>> On Tue, Sep 22, 1998 at 08:41:38PM +0200, Werner Koch wrote:
>> > Here is the reason, why I do not like time conversion:
>> >
>> > pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
>> > ^^^^^^^^^^
>> >
>> > This may get listed as -07-08 or -07-06 depending on the timezone.
>> > I think that this could lead to some confusion if two persons list the
>> > key but get different times (yes they are not different really, but it
>> > seems so)
>> >
>> > I all other cases a localized time is okay for me.
>>
>> I believe that using mix of gmt and localized times may lead to other
>> confusions. My vote goes for having an option that control how *all* times
>> are considered.

>I would disagree with your statement that mixing gmt and local time will
>cause confusion. What will cause confusion is mixing of semantics. When
>you are using a date to represent when something occured in the context of
>the person using the software, you ought to use the local time. If you
>are using a date that is to identify something external, such as when a
>key was created, you should use UTC.

i disagree. even if the time refers to an external event,
displaying that time is done in the context of a user using
the software that displays that time.

btw, when you say "use" to you mean storage or display?
it's not clear. imho all times should be stored in UTC always.
display is another matter but whatever is decided, display the
timezone as well. then, werner's example ceases to be confusing.

if the time is displayed in UTC and states that fact, there is
no ambiguity. if the time is displayed locally and states that
fact, there is no ambiguity.

raf

raf@comdyn.com.au (raf) writes:

> Werner wrote:
>
> >Michael Deindl <olmur@dwarf.bb.bawue.de> writes:
>
> >> I want to support this suggestion: local time is usually a good idea
> >> and should be the default. But having an option to switch to UTC is a
>
> >Here is the reason, why I do not like time conversion:
>
> >pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
>
> >This may get listed as -07-08 or -07-06 depending on the timezone.
> >I think that this could lead to some confusion if two persons list the
> >key but get different times (yes they are not different really, but it
> >seems so)
>
> i don't understand. how can it lead to confusion
> if these two people are in different timezones?
>
> raf

Suppose I created a key right now. It's 1998-09-22 where I am, but in Germany
it's 1998-09-23. Four months from now when you list your keyring and see my
key, what date should it list as a creation date? Does it depend upon where
you are living at the time?

The same holds true for recording when signatures are made. I'm afraid that my
preference is to display the date local to the creator or signator: If I
signed a document at a point when my time zone was in Thursday, then when you
check the signature it should report that the signature was made in that time
zone on a Thursday. Unfortunately this would mean keeping a timestamp *and* a
zone offset (or worse.. those modern POSIXish? timezone structures come to
mind) in with the signatures.

Failing that, always display it the same way, but have that way be a user
preference, and full timestamps should be displayed in a way that indicates
which way the user preferred (with a -0700 or a UTC or something).

cheers,
-Brian

Warner wrote:

>raf@comdyn.com.au (raf) writes:

>> Werner wrote:
>>
>> >Michael Deindl <olmur@dwarf.bb.bawue.de> writes:
>>
>> >> I want to support this suggestion: local time is usually a good idea
>> >> and should be the default. But having an option to switch to UTC is a
>>
>> >Here is the reason, why I do not like time conversion:
>>
>> >pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
>>
>> >This may get listed as -07-08 or -07-06 depending on the timezone.
>> >I think that this could lead to some confusion if two persons list the
>> >key but get different times (yes they are not different really, but it
>> >seems so)
>>
>> i don't understand. how can it lead to confusion
>> if these two people are in different timezones?
>>
>> raf

>Suppose I created a key right now. It's 1998-09-22 where I am, but in Germany
>it's 1998-09-23. Four months from now when you list your keyring and see my
>key, what date should it list as a creation date? Does it depend upon where
>you are living at the time?

it depends on whatever we want it to depend on. hence this discussion.

consider what the use of this displayed date is. it's to tell me whether
or not the key has expired. for me to be able to do that, i must know what
the originating timezone is to convert into my own timezone. it sounds
like you are suggesting: use the originator's timezone but don't tell
anyone what that is :) [.only joking - you don't say that below but the
example time shown above is lacking the timezone].

>The same holds true for recording when signatures are made. I'm afraid that my
>preference is to display the date local to the creator or signator: If I
>signed a document at a point when my time zone was in Thursday, then when you
>check the signature it should report that the signature was made in that time
>zone on a Thursday.

that would be fine: the originator's timezone is stated.
otoh, gnupg doesn't have to tell me where you live.
it only has to tell me when your key has expired.

>Unfortunately this would mean keeping a timestamp *and* a
>zone offset (or worse.. those modern POSIXish? timezone structures come to
>mind) in with the signatures.

without the timezone, the time itself is meaningless
so i'd think it's worth storing the timezone.
and btw, just the offset is needed (as calculated with
those "modern "POSIXish timezone structures" on the
originating host).

>Failing that, always display it the same way, but have that way be a user
>preference, and full timestamps should be displayed in a way that indicates
>which way the user preferred (with a -0700 or a UTC or something).

yes, i agree that the timezone should be displayed whether
it is stored or not.

summary:

if timezones are stored, then everybody can have whatever they want.

if not, then a single timezone must be assumed by everyone.
that would have to be UTC. in this case, dates could either
be displayed in UTC or in the user's local timezone. there
would be no possibility of knowing a key creator's timezone
and hence no way of displaying times in that timezone.

if enough people think that that is unacceptable, then
timezones have to be stored.

otherwise only UTC and the user's local timezone are available
for display.

in that case, the user may be given the ability to specify
which of the two timezones to use for particular times and
whether or not to display the timezones used.

but i think someone would be mad to want to use different
timezones without seeing what those timezones are.

raf

Michael Sobolev <mss@despair.transas.com> writes:

> result, the key creation time should always be displayed using gmtime (3)
> function, while all other times -- using localtime (3) or gmtime (3) according

Okay, that's what I'm going to do. Is an option "--gmtime" okay to
override the use of localtime and do we really need such an option?

What about

$ TZ=UTC gpg .....

I think this is the POSIX way.


Werner

Some clarification:

- times are always stored in UTC. This is required by OpenPGP and
nothing else would make sense. Telling which timezone has been
used to create a message is out of the scopenof gnupg - the
mail headers may tell you this.

- Who cares about the timezone anyway. I think in CE[S]T because I
live here and I use this timezone for my calendar too :-).

- It is convenient to display localized times and if there is enough
room on the screen the current timezone may also be displayed.

- I think of the key creation time as an attribute of the key (and it
is one because it gets signed) like number of bits, algorithm,
fingerprint. Because of that I think the time should be displayed
in UTC in all key listings.
A: "okay, I have here your key: 1024 bits, DSA created on 1998-09-01"
B: "Oops, that is not my key, I created it 1998-08-31"
This may happen if A and B are in different timezones.

- If a program gives more detailed or better formatted information
about a key it should display the time in the preferred localized
format, which would be
Dienstag 23 September 1998 MESZ
in Germany (or another recognized format) or
Monday September 23rd 1998 PST
somewhere else.

- The documentation should tell that the times which are listed are
always in YYYY-MM-DD format and in UTC.



Werner

>>>>> "Werner" == Werner Koch
>>>>> "Re: dates and their representation"
>>>>> Wed, 23 Sep 1998 09:09:28 +0200

Werner> Michael Sobolev <mss@despair.transas.com> writes:
>> result, the key creation time should always be displayed using
>> gmtime (3) function, while all other times -- using localtime
>> (3) or gmtime (3) according

Werner> Okay, that's what I'm going to do. Is an option
Werner> "--gmtime" okay to override the use of localtime and do we
Werner> really need such an option?

Werner> What about

Werner> $ TZ=UTC gpg .....

Werner> I think this is the POSIX way.

Is there a privacy issue with storing local time at all? Maybe even
as an option it can lead to unwanted disclosure.

jam

On Wed, Sep 23, 1998 at 09:09:28AM +0200, Werner Koch wrote:
> Okay, that's what I'm going to do. Is an option "--gmtime" okay to
> override the use of localtime and do we really need such an option?
Great.

> What about
>
> $ TZ=UTC gpg .....
>
> I think this is the POSIX way.
Yes, this can be used in case two person cannot agree on when a key was
created. :)

--
Mike

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "WK" == Werner Koch <wk@isil.d.shuttle.de> writes:

WK> Here is the reason, why I do not like time conversion:

WK> pub 1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
WK> ^^^^^^^^^^

WK> This may get listed as -07-08 or -07-06 depending on the timezone.

this is the reason why I usually write the month with its
(abbreviated) name instead of its number: this avois the confusion if
01-07 is in the middle of winter or in the middle of summer (7th
Januar and 1st July are quite distictive).

Maybe GPP can do something like this as well.

Bye,
Michael

- --
PGP Key on Servers -- Finger-Print: 51ECA5D2 13938F91 CBF76CC4 F8B5B67C

Hackers do it with fewer instructions.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNgrCNg9NARnYm1I1AQFvawP+OM3SLBVy7bu7wviGOKbplMR3lsSN8tX0
6bdqTYYQWOY0WkCTl+aftAG1PohBSw3uD7IT1EnxgQ52dWYqApPZrxwaC1CoG/+z
fv4naPUfeNlkUdHw/HXsPJjsgxlpyX7z6nQuV98qg6TuxTdsv9W+7Ln0e/LTBfuE
u7BVOO1pyaw=
=XoQ4
-----END PGP SIGNATURE-----

Michael Deindl <olmur@dwarf.bb.bawue.de> writes:

> WK> This may get listed as -07-08 or -07-06 depending on the timezone.
>
> this is the reason why I usually write the month with its
> (abbreviated) name instead of its number: this avois the confusion if
> 01-07 is in the middle of winter or in the middle of summer (7th
> Januar and 1st July are quite distictive).

I was wrong: There is no ambiguity when using "yyyy-mm-dd" this
format is not good to read but very easy to understand my machines.


Werner

At around Fri, 25 Sep 1998 10:36:53 +0200,
Werner Koch <wk@isil.d.shuttle.de> may have mentioned:

> Michael Deindl <olmur@dwarf.bb.bawue.de> writes:
>
> > WK> This may get listed as -07-08 or -07-06 depending on the timezone.
> >
> > this is the reason why I usually write the month with its
> > (abbreviated) name instead of its number: this avois the confusion if
> > 01-07 is in the middle of winter or in the middle of summer (7th
> > Januar and 1st July are quite distictive).
>
> I was wrong: There is no ambiguity when using "yyyy-mm-dd" this
> format is not good to read but very easy to understand my machines.
^^^^^^^^^^^^^^^^

it didn't take me long to get used to it -- i write almost all of my
dates in that format now :-)

On Fri, 25 Sep 1998 sen_ml@eccosys.com wrote:

> At around Fri, 25 Sep 1998 10:36:53 +0200,
> Werner Koch <wk@isil.d.shuttle.de> may have mentioned:
>
> > Michael Deindl <olmur@dwarf.bb.bawue.de> writes:
> >
> > > WK> This may get listed as -07-08 or -07-06 depending on the timezone.
> > >
> > > this is the reason why I usually write the month with its
> > > (abbreviated) name instead of its number: this avois the confusion if
> > > 01-07 is in the middle of winter or in the middle of summer (7th
> > > Januar and 1st July are quite distictive).
> >
> > I was wrong: There is no ambiguity when using "yyyy-mm-dd" this
> > format is not good to read but very easy to understand my machines.
> ^^^^^^^^^^^^^^^^
>
> it didn't take me long to get used to it -- i write almost all of my
> dates in that format now :-)
>

I believe the yyyy-mm-dd format is also known as 'international' date
format. For my purposes it has the very nice effect of a text sort
producing date sorted material.

I don't know of any regional convention that uses the yyyy-dd-mm format
with the '-' separator, I believe that it is customary in the vast
majority of locales to use '/' or '.'. Perhaps someone more travelled can
provide some perspective.

Does anyone know of an iso standard that attempts to enumerate these? All
Microsoft and many other applications treat mm/dd/yyyy as being the 'US'
format however I always switch it to the above format for consistency.

C=)

--------------------------------------------------------------------------
There is hardly a thing in the world that some man can not
make a little worse and sell a little cheaper.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: 1024D/7BBB1485
--------------------------------------------------------------------------
I didn't fight my way to the top of the food chain to be a vegetarian.

At 03:02 -0700 1998-09-25, Caskey L. Dickson wrote:
>I believe the yyyy-mm-dd format is also known as 'international' date
>format. For my purposes it has the very nice effect of a text sort
>producing date sorted material.
>
>Does anyone know of an iso standard that attempts to enumerate these?

Yes, ISO 8601; try these URLs:
<http://www.cl.cam.ac.uk/~mgk25/iso-time.html>
<http://www.mcs.vuw.ac.nz/comp/Technical/SGML/doc/iso8601/ISO8601.html>
--
Joel Klecker (aka Espy)
<URL:mailto:jk@espy.org> <URL:http://web.espy.org/>
Debian GNU/Linux user/developer on i386 and powerpc.
<URL:mailto:espy@debian.org> <URL:http://www.debian.org/>

IMHO, the Right Thing to do with dates is:

- store and transmit dates in UTC (although if you're storing "seconds
since epoch", you don't even store a time zone at all)
- display ALL dates according to the user's locale settings

It's a bad idea to store the time zone where a key was generated or
signature made, because that reveals what part of the world the key or
signature originates from, and that could very well be something the user
would want to conceal. It's bad even to store the time zone optionally,
because it becomes a sort of subliminal channel.

It's a good idea to display dates according to the user's locale settings,
because that's what other programs do, and that's what the locale settings
are *for*. If the user wants to see dates in GMT, let them set their time
zone to GMT (although you could make that an option if you really had to).

Note that email transmits zone information and user agents (pine at least)
display it unchanged; news also transmits zone information but user agents
usually translate it to the reader's zone. DOS filesystems store local
time without storing the time zone (unless NT has changed this). Unix
filesystems store standardized time (seconds since epoch) without time
zone, and Unix programs always display filesystem times according to
locale settings.

"Let me lose so beautifully http://www.islandnet.com/~mskala/
Let me lick the dew from the money tree Matthew Skala
Have the moms of the world all care about me Ansuz BBS
At suppertime" - Odds (250) 472-3169

>>>>> "Matthew" == Matthew Skala
>>>>> "Re: dates and their representation"
>>>>> Sat, 26 Sep 1998 19:55:49 -0700 (PDT)

Matthew> IMHO, the Right Thing to do with dates is:
Matthew> - store and transmit dates in UTC (although if you're
Matthew> storing "seconds since epoch", you don't even store a
Matthew> time zone at all)
Matthew> - display ALL dates according to the user's locale
Matthew> settings

FWIW I agree with both points.

Matthew> It's a bad idea to store the time zone where a key was
Matthew> generated or signature made, because that reveals what
Matthew> part of the world the key or signature originates from,
Matthew> and that could very well be something the user would want
Matthew> to conceal. It's bad even to store the time zone
Matthew> optionally, because it becomes a sort of subliminal
Matthew> channel.

It is, IMHO, of utmost importance not to store or transmit a local
time zone. Providing an option not only provides a way for it to leak
out but provides an indication of the user's intent which could itself
be damaging.

jam

Silly me, I respond to my own mail after having read the specs. I had
not supposed from the drift of previous posts in this thread that the
time representation was apparently settled in the OpenPGP draft as
being UTC the same as in rfc1991. Apparently I was not alone, but
only the last to be so silly. :-)

>>>>> "jam" == John A Martin
>>>>> "Re: dates and their representation "
>>>>> Sun, 27 Sep 1998 08:34:45 -0400

>>>>> "Matthew" == Matthew Skala
>>>>> "Re: dates and their representation"
>>>>> Sat, 26 Sep 1998 19:55:49 -0700 (PDT)

Matthew> IMHO, the Right Thing to do with dates is:
Matthew> - store and transmit dates in UTC (although if you're
Matthew> storing "seconds since epoch", you don't even store a
Matthew> time zone at all)
Matthew> - display ALL dates according to the user's locale
Matthew> settings

Sections 3.5 of both the draft-ietf-openpgp-formats-07 and rfc1991
specify that time fields carry the number of seconds elapsed since
midnight, 1 January 1970 UTC (GMT) [the Unix Epoch].

jam> FWIW I agree with both points.

I am no longer so sure about the second point.

Matthew> It's a bad idea to store the time zone where a key was
Matthew> generated or signature made, because that reveals what
Matthew> part of the world the key or signature originates from,
Matthew> and that could very well be something the user would want
Matthew> to conceal. It's bad even to store the time zone
Matthew> optionally, because it becomes a sort of subliminal
Matthew> channel.

jam> It is, IMHO, of utmost importance not to store or transmit a
jam> local time zone. Providing an option not only provides a way
jam> for it to leak out but provides an indication of the user's
jam> intent which could itself be damaging.

The OpenPGP draft and rfc1991 both do the right thing to preserve
privacy.

As to the local display of time or date it seems that with UTC being
an integral part of PGP it might be least confusing to always display
UTC. Recall that is what earlier PGPs did sometimes accompanied with
a "Current time: yyyy/mm/dd hh:mm GMT" after the copyright banner.

I make these remarks after having become fairly confused looking at
gpg outputs from distant systems. Perhaps best would be consistent
and unadorned UTC times with an optional "Current time ... UTC" ahead
of outputs showing times or dates, though the current time seems to me
like gilding the lily.

Please excuse my earlier responses to this thread without having
consulted the pertinent documentation.

jam