dates and their representation

[raf]

Warner wrote:

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

>> Werner wrote:
>> 
>> >Michael Deindl <olmur at 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 at 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