SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Mon, 5 Apr 2004 06:41:49 PST8PDT,4,1,0,3600,10,-1,0,7200,3600
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: SCOUG Server - time restamp on messages (was: doesn't like TZ variable)

Content Type: text/plain

> Peter Skye said:
>
> >AFAIK this isn't an INetMail problem; I
> >think this is a custom SCOUG routine.

Steven Levine wrote:
>
> Nope. It's just the way Steward is coded.
>
> TimeZone = value( 'TZ', , Env)
> rc = lineout(OutFile, 'Date:' DayOfWeek',' TmpDate TmpTime TimeZone, )

Thanks, I didn't realize Steward was distributed with the date-time
restamp code. The code you found appears three different times in
Steward's Message.cmd file.

Decision on date-time restamping
================================

So we need to either

-- 1) remove the date-time restamping (there might be a setup option in
the InetMail notebook to do this), or

-- 2) write a Rexx routine that returns the current time zone in an
SMTP-compliant format

Time zone compliancy
====================

Relevant to writing such code: RFC 2822 changed the compliancy for
date-time stamping and non-numeric time zones (in our case PST and PDT
are no longer allowed - see RFC 2822 paragraph 4.3). RFC 2822 also
specifies that if the time zone is unknown (in our case if TZ is
misformed and the time zone value cannot be extracted successfully) then
the time zone should be -0000. -0000 should not be confused with +0000;
the former indicates "unknown" and the latter "Universal Time", as per
RFC 2822.

TZ processing
=============

Extracting the time zone group from TZ is not difficult. It is the
first field in the TZ string which itself is in CSV format.

Daylight Saving determination
=============================

That leaves the determination of whether or not Daylight Saving time is
currently in effect. The TZ string may contain eight additional numeric
fields which specify the spring and fall boundaries for the change,
*but* (and it's a big "but") there's no way to easily determine whether
or not Daylight Saving time is in effect during the one hour
"duplicated" time period in the fall. In other words, at 1:30 a.m. on
the last Sunday morning of October (in the United States for Daylight
Saving regions) you cannot easily determine if you are currently
operating under Daylight Saving or not. And if the TZ string does not
contain the additional eight fields then no Daylight Saving
interpretation can be done.

There is no "Daylight Saving" flag that I'm aware of in either OS/2 or
the Workplace Shell which can be referred to. I do not know if other
platforms (i.e. non-OS/2 operating systems) have a "Daylight Saving"
flag and it would be interesting to know how they implement such a flag.

The only trustworthy determination method I can think of is to access a
time server (NTP), compare the returned value to the local clock time,
and use the result as the time zone offset. NTP servers are pretty
quick (when they're accessible; I use about a dozen and there's usually
at least one which is not responding) and an existing NTP client such as
Daytime.exe may be used to retrieve the time. The NTP server time need
not be retrieved for every message; for example, if the NTP time is
retrieved for a message at 2:01 a.m. then that same value may be used
for a message at 2:02 a.m.

The conclusion is obvious. For time zone determination, TZ should not
be used.

Comments, please.

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 05 | April | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.