<HTML>
<!-- $Id$ -->
<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: &lt;current offset from UTC&gt;

  The offset has the format &lt;[-]hhmm&gt;, 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">Go Back</A>

</BODY>
</HTML>