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