211 lines
6.4 KiB
HTML
211 lines
6.4 KiB
HTML
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>Timezone information in FTN messages.</TITLE>
|
||
|
|
</HEAD>
|
||
|
|
|
||
|
|
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
|
||
|
|
<BODY
|
||
|
|
BGCOLOR="#FFFFFF"
|
||
|
|
TEXT="#000000"
|
||
|
|
LINK="#0000FF"
|
||
|
|
VLINK="#000080"
|
||
|
|
ALINK="#FF0000"
|
||
|
|
>
|
||
|
|
<PRE>
|
||
|
|
**********************************************************************
|
||
|
|
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
|
||
|
|
**********************************************************************
|
||
|
|
|
||
|
|
Publication: FSP-1001
|
||
|
|
Revision: 2
|
||
|
|
Title: Timezone information in FTN messages
|
||
|
|
Author: Odinn Sorensen, 2:236/77
|
||
|
|
Revision Date: 27 September 1997
|
||
|
|
Expiry Date: 13 September 1999
|
||
|
|
----------------------------------------------------------------------
|
||
|
|
Contents:
|
||
|
|
1. Scope
|
||
|
|
2. Current practice
|
||
|
|
3. Kludge specification
|
||
|
|
4. Timezone table
|
||
|
|
5. Examples
|
||
|
|
----------------------------------------------------------------------
|
||
|
|
|
||
|
|
|
||
|
|
Status of this document
|
||
|
|
-----------------------
|
||
|
|
|
||
|
|
This document is a Fidonet Standards Proposal (FSP).
|
||
|
|
|
||
|
|
This document specifies an optional Fidonet standard protocol for
|
||
|
|
the Fidonet community, and requests discussion and suggestions for
|
||
|
|
improvements.
|
||
|
|
|
||
|
|
This document is released to the public domain, and may be used,
|
||
|
|
copied or modified for any purpose whatever.
|
||
|
|
|
||
|
|
|
||
|
|
Abstract
|
||
|
|
--------
|
||
|
|
|
||
|
|
Current practice for Fidonet Technology Network (FTN) messages is to
|
||
|
|
store dates in local time. Timezone information (if known) is
|
||
|
|
usually lost. This document specifies a standard for storage of
|
||
|
|
timezone information in FTN messages, in the form of a kludge named
|
||
|
|
TZUTC.
|
||
|
|
|
||
|
|
|
||
|
|
1. Scope
|
||
|
|
--------
|
||
|
|
|
||
|
|
This standard is specified for FTN messages in any form where
|
||
|
|
timezone information is not integrated in the message storage or
|
||
|
|
transport format. Specifically any form where the information would
|
||
|
|
be lost if not stored in a kludge, such as in FTS-1 stored messages
|
||
|
|
or packets.
|
||
|
|
|
||
|
|
|
||
|
|
2. Current practice
|
||
|
|
-------------------
|
||
|
|
|
||
|
|
Some kludges already exist to specify the timezone of messages,
|
||
|
|
notably "TZUTC" and "TZUTCINFO". Other kludges may exist.
|
||
|
|
|
||
|
|
To the authors knowledge, no official specification exists for any
|
||
|
|
of these kludges.
|
||
|
|
|
||
|
|
From observations of these kludges in actual messages, TZUTC and
|
||
|
|
TZUTCINFO are identical except for the name. TZUTCINFO is probably
|
||
|
|
named after the JAM msgbase subfield of the same name.
|
||
|
|
|
||
|
|
This document adopts and documents the TZUTC kludge because it is
|
||
|
|
the shortest of them.
|
||
|
|
|
||
|
|
|
||
|
|
3. Kludge specification
|
||
|
|
-----------------------
|
||
|
|
|
||
|
|
Messages which conform to this specification must add the kludge:
|
||
|
|
|
||
|
|
^aTZUTC: <current offset from UTC>
|
||
|
|
|
||
|
|
The offset has the format <[-]hhmm>, where hhmm is the number of
|
||
|
|
hours and minutes that local time is offset from UTC. If local time
|
||
|
|
is WEST of UTC (Greenwich), then the offset is NEGATIVE. See the
|
||
|
|
table below for typical offsets.
|
||
|
|
|
||
|
|
Note that the hh in a timezone offset is not limited to a maximum of
|
||
|
|
12. This is because the International Date Line does not run exactly
|
||
|
|
along the boundary between zone -1200 and +1200. The minutes part is
|
||
|
|
00 for most timezones.
|
||
|
|
|
||
|
|
All four digits must be present. If the offset is negative, there
|
||
|
|
must be a minus ('-', ASCII 45, 2Dh) in front of the offset.
|
||
|
|
|
||
|
|
Implementations must NOT put a plus ('+', ASCII 43, 2Bh) in front of
|
||
|
|
the offset for positive numbers, but robust implementations should
|
||
|
|
be prepared to find (and ignore) a plus if it exists.
|
||
|
|
|
||
|
|
If local time changes as a result of, for example, daylight savings
|
||
|
|
time, then the offset in TZUTC need to be changed to reflect this.
|
||
|
|
|
||
|
|
When this kludge is present in a message, the "date written" field
|
||
|
|
in the stored message is guaranteed to be in local time for the
|
||
|
|
given timezone. Note that this specification does not specify the
|
||
|
|
timezone for any other date fields. Other date fields (such as "date
|
||
|
|
received, arrived, processed, etc.") are usually in local time for
|
||
|
|
the system on which the messages are stored.
|
||
|
|
|
||
|
|
|
||
|
|
4. Timezone table
|
||
|
|
-----------------
|
||
|
|
|
||
|
|
This table gives examples of typical timezones.
|
||
|
|
|
||
|
|
-1000 Alaska-Hawaii Standard Time
|
||
|
|
-0900 Hawaii Daylight Time
|
||
|
|
-0800 Pacific Standard Time
|
||
|
|
-0700 Pacific Daylight Time
|
||
|
|
-0700 Mountain Standard Time
|
||
|
|
-0600 Mountain Daylight Time
|
||
|
|
-0600 Central Standard Time
|
||
|
|
-0500 Central Daylight Time
|
||
|
|
-0500 Eastern Standard Time
|
||
|
|
-0400 Eastern Daylight Time
|
||
|
|
-0400 Atlantic Standard Time
|
||
|
|
-0330 Newfoundland Standard Time
|
||
|
|
-0300 Atlantic Daylight Time
|
||
|
|
-0100 West Africa Time
|
||
|
|
0000 Greenwich Mean Time
|
||
|
|
0100 Central European Time
|
||
|
|
0100 British Summer Time
|
||
|
|
0200 Central European Summer Time
|
||
|
|
0200 Eastern European Time
|
||
|
|
0800 Australian Western Time
|
||
|
|
0800 China Coast Time
|
||
|
|
0900 Japan Standard Time
|
||
|
|
0900 Australian Western Daylight Time
|
||
|
|
0930 Australian Central Standard Time
|
||
|
|
1000 Australian Eastern Standard Time
|
||
|
|
1030 Australian Central Daylight Time
|
||
|
|
1100 Australian Eastern Daylight Time
|
||
|
|
1200 New Zealand Standard Time
|
||
|
|
1300 New Zealand Daylight Time
|
||
|
|
|
||
|
|
|
||
|
|
5. Examples
|
||
|
|
-----------
|
||
|
|
|
||
|
|
^aTZUTC: 0000
|
||
|
|
^aTZUTC: 0200
|
||
|
|
^aTZUTC: -0700
|
||
|
|
|
||
|
|
|
||
|
|
6. Redundancy
|
||
|
|
-------------
|
||
|
|
|
||
|
|
If the TZUTC data duplicates a field in a storage format in such a
|
||
|
|
way that no information is lost in conversion to or from the field,
|
||
|
|
then it is recommended that the kludge is not stored in the message.
|
||
|
|
However, implementations are allowed to store the TZUTC even when
|
||
|
|
redundant.
|
||
|
|
|
||
|
|
|
||
|
|
A. References
|
||
|
|
-------------
|
||
|
|
|
||
|
|
[FTS-1] "A Basic FidoNet(r) Technical Standard Revision 16", Randy
|
||
|
|
Bush. September 1995.
|
||
|
|
|
||
|
|
[JAM] "The JAM message base proposal", Joaquim Homrighausen, Andrew
|
||
|
|
Milner, Mats Birch and Mats Wallin. July 1993.
|
||
|
|
|
||
|
|
|
||
|
|
B. Author contact data
|
||
|
|
----------------------
|
||
|
|
|
||
|
|
Odinn Sorensen
|
||
|
|
Fidonet: 2:236/77
|
||
|
|
E-mail: odinn@goldware.dk
|
||
|
|
WWW: http://www.goldware.dk
|
||
|
|
|
||
|
|
|
||
|
|
C. History
|
||
|
|
----------
|
||
|
|
|
||
|
|
Rev.1, 970913: First release.
|
||
|
|
Rev.2, 970927: Updated the timezone table. Added section about
|
||
|
|
redundancy. Clarified what happens when local time
|
||
|
|
changes. Clarified some of what the specification
|
||
|
|
doesn't cover.
|
||
|
|
|
||
|
|
|
||
|
|
**********************************************************************
|
||
|
|
</PRE>
|
||
|
|
|
||
|
|
<A HREF="index.htm"><IMG SRC="../images/b_arrow.gif" ALT="Back" Border="0" width="33" height="35"> Go Back</A>
|
||
|
|
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|
||
|
|
|