    **********************************************************************
    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:

      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.

    **********************************************************************

Go Back