bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed HTML codes in Fidonet documents

Browse Source
This commit is contained in:
Michiel Broek
2002-02-16 21:38:40 +00:00
parent 1fb610f935
commit 0aa608b565
42 changed files with 18330 additions and 18508 deletions
Download Patch File Download Diff File Expand all files Collapse all files

421
html/ftsc/fsp-1001.html
View File

@@ -1,210 +1,211 @@
<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>
<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>