[SpamCop-List] Re: Planned outage of SpamCop Reporting Service

[Mike Easter]

Frank Ellermann wrote:
> Mike Easter wrote:
>
>> PDT & PST is very very well accepted.
>
> No, it's not very well aceepted.  Whenever I look at SC's
> statistics I have no idea what EDT really is in my time :-(

We are getting 2 different arguments 'mixed up' so I'm going to have to
ramble a little bit.  The only 'sphere' I'm defending the usage of
something like PDT [UTC -0700] or PST [UTC -0800] is when 'we'/I am
talking about time from my localtime perspective, like 'me', I did such
and so.  /I/ get to be Pacific time -centric personally, but I show the
offset when I know I am talking to other timezones.

I'm not trying to defend SC being Pacific time -centric.

As I said in an earlier post, whenever I think about something that is
very 'international' like email, I think in terms of UTC.  When I look
at email headers I 'see' them in UTC, not Pacific time.  If 'I' were SC,
I should be thinking in UTC, like mail or anything else international.
SC is international.

>> If a European is confused about whether the 'S' means
>> summer or standard, they should consult their table
>
> Starting from CET (central European time) I'd be tempted
> to use CST for summer time, or CDT for daylight savings,
> but both are bad.  If I'd use CEST or CEDT some programs
> still expecting 3 letters fail.

I don't know how we are going to successfully argue how standard the
'tables' I'm familiar with are compared to some other tables you might
think of that I don't know about.  When I first started discussing this
thread I cited this particular set of tables:
http://www.timeanddate.com/library/abbreviations/timezones/

In those tables -  temporarily assuming they are absolutely correct and
anything found in contradistinction must therefore be wrong ;-)  --
Central European Time is expressed as CET [+1] and CEST [+2] and, there
are potentially confusing ambiguities, which is why 'correct' tables
should be used;  such as North American Central, CST [-6];  Australian
Central, CST [+9];  and their respective daylight times, also ambiguous
at CDT.

My point about Pacific time was that no such confusion exists about PDT
& PST, not that it was easily and quickly recognized all over the world.
Just that there aren't likely to be confusing alternate tables
somewhere, unless there are and I don't know about it.

> Therefore there are no "standard abbreviations" in great
> parts of the world, and the least common denominator is
> "internet time" (UTC, Zulu, GMT).

I understand the value of internet, atomic, universal time and agree.

>> When I use a term like PDT I also refer to its offset
>> from UTC or Z time to save someone else the trouble of
>> going to a table.
>
> That's a possible solution, but unfortunately you haven't
> written the program for SC's statistics.  The problem is
> that I know the difference of my local timezone from GMT,
> but it's easy to get confused by _two_ differences like
> PDT = GMT -5 and local = GMT +2.

Again, I don't want to defend SC's choice of PDT wherever that might
happen.

> Posting this at 21:17 of my local time = GMT +2, do you
> immediately get your local time from this statement ?
> It's IMHO much clearer for you if I'd say 19:17Z.  Bye.

Actually, I'm perfectly 'comfortable' with you expressing your local
time with offset - that way I get the picture that you are posting this
at what I would call about 9 o'clock in the evening.  That has meaning.
It is also helpful for you to tell me the offset.

It isn't really important for me to know what time it was UTC or Pacific
time, in this /particular/ case - but if it were, I would have to make a
2 step transition, as you say.  But, if I needed to know all 3 values,
your local time, UTC, and my local time for a particular observation,
either the writer would have to express it in 3 ways or else leave at
least a part of the work up to the reader.

-- 
Mike Easter
kibitzer, not SC admin