>cthuang@io.org (Chin Huang) wrote:
>>In article <9wBDxQGibKFU089yn@login.dknet.dk>,
>
>>Your TZ setting is incorrect. Use a negative number to represent
>>a time zone east of Greenwich.
>>
>> set TZ=CET-1
>
>I must admit I find this part of YARN confusing. For example, how
>far east of greenwich before it becomes west? Over the dateline in
>the middle of the Pacific? Here I sit in Japan, and can't figure
>out what my TZ should be.
>
<snip>
>
>Somebody care to fill in the details for us? (especially that JPN)
>
Being a bear of very little brain, I console me by explaining it to
myself like this.
Picture yourself in London, standing on the Greenwich meridian facing
North. Then imagine that the Earth is unzipped along the dotted
line down the other side of the globe directly opposite where you're
standing, the 180th meridian (the dateline, give or take a few minor
zigzags). Peel the surface back from along that line, and lay the
world out flat.
Now the confusing ambiguity of east/west +/- and the dateline is easier
to resolve. Everything to the right of you is east and everything to
the left is west - all the way to the metaphorical horizon at the 180th
meridian on either hand.
Except for Spain and the knobbly bit of Africa that sticks out into
the Atlantic, all of Europe, Africa, the Middle East, India, Russia
including Siberia, China, Korea, Japan, South East Asia, Australia, and
New Zealand lie to your _right_ between you and the dateline. All of
these places are therefore East of Greenwich, and the system TZ
adjustment should be signed "minus" relative to UTC/GMT. They see the
sun each day _before_ London does. That is, to index their local
sunrise to the Greenwich time equivalent it is necessary to _subtract_
the differential from local time.
To your left as you stand on the Greenwich meridian, all of Greenland,
North America including Alaska, Central America and South America lie
between you and the dateline on that side to the West. For them the
system TZ correction should be signed "plus" relative to UTC. They see
the morning sun _after_ London does, and in order to index their local
sunrise to Greenwich it is necessary to _add_ the differential to local
time.
A further adjustment that might be applicable is for local summer time.
But it's important to visualise this strictly as an adjustment to
_local_ time (which is what it is), not an adjustment to Greenwich time
(which stays immutable).
So, where I am (New Zealand, nearly but not quite 180 degrees East of
Greenwich) the local time zone is 12 hours ahead of Greenwich on
standard time, but is 13 hours ahead on summer time. Thus the standard
system TZ adjustment here is -12, which goes to -13 in summer time.
The extra summertime hour might look trivial, but neglecting it can
lead to complications. If it isn't included in the TZ setting and I
try to post an article to a newsgroup inside an hour of the originating
time stamp the server will interpret the post as being in the future.
That is, suppose I try to post an article with an originating local
time stamp in the header of 1000 hours at, say, 1030 hours local summer
time here. If the TZ adjustment is still set erroneously at -12 hours
when it should be at -13 hours for summer time, the server will index
the 1000 local time stamp back to Greenwich by subtracting the 12 hours
TZ setting, and will read it as 2200 hours UTC/GMT (the evening before;
but that doesn't matter for present purposes). But when I actually
dispatched the article at 1030 hours local time, the Greenwich time was
in fact 1030-13 = 2130 hours, or half an hour in advance of the
erroneously indexed time stamp. The server knows the real time, and
says in effect "up with this I will not put; some turkey is trying to
arrive before he has left". Hence the rejection "posted into the
future". (Obviously, if in these circumstances I had dispatched the
same posting with the same 1000 local time stamp at any local time
after the summertime hour's additional differential had elapsed - say
at 1130 local - this situation would not arise. The time stamp would
still be indexed back to the same 2200 hours Greenwich but the message
would be received by the server at 2230 hours Greenwich time. Result,
happiness; even though the TZ setting remained in error by an hour!)
Confused? So am I. The technical purists might object to parts of the
above, but as far as I'm concerned it fits with simple observations and
will do for the time being.
An additional confusion may be that you'll find a minus x setting in
the system TZ statement will turn up as a plus x adjustment in the
header time line of a message you originate; and a plus x will become a
minus x similarly. The easiest, though again probably over-simplified,
interpretation of this is that Yarn is being helpful in showing you a
local time because that's where you're at after all, but also that the
correction factor _from_ Greenwich rather than _to_ Greenwich is as you
see it.
Finally, there is a SET TZ syntax that will take care of all this
including the dates and times, and the quantum, of changes between
local summer time and standard local time. For Yarn/2 specifically,
however, running under OS/2 Warp Connect and also Warp 4, I can't make
the form associated with RFC868 (SET TZ=SSSnDDD,n,n,n,n,n,n,n,n,n if I
have that right) work properly.
After a lot of plagiarism and mucking about and, quite honestly, never
really understanding what I was doing, the following seems to work.
I means that the time zone is set for NZ, 12 hours standard time east
of Greenwich, changing to summer time in September and back to standard
time in March, in each case on the Sunday (Day 0) of the fourth week of
the respective month, at 1am in the first case and at 2:15am in the
second (I think):
SET TZ=NZT-12NZD,M9.4.0/1:00,M3.4.0/2:15
but I offer no guarantees!
--
Robin Klitscher
Wellington ("Harbour City") NZ