Mail To: Jos den Bekker <stik-beta-testers@spodden.zetnet.co.uk>
Subject: Re: STinG & Infitra (+other STinG problem)
----------------------------------------------------------------------------

On Sun, 31 May 1998, Jos den Bekker wrote:
>on Fri 29-05-98 17:06 Eabe Kuik wrote:
>
>>Why don't you make a proposal of how you think the creation of a time stamp 
>>should be implemented. If it is a good proposal I will implement it in 
>>Infitra. But until that I keep it the way it is.
>
>My pleasure. You need to get information fro the user about time 
>zone, DST offset, plus the rules for start and end of the DST period, 
>of course. I suggested you use the convention for the TZ environment 
>variable for this. This is also what programs compiled with the GNU 
>C-compiler use at start-up to determine GMT offset and DST value for 
>struct tm. Appended to this message you will find a doc expaining the 
>syntax for this variable, but you can use your own system instead in 
>your configuration files, of course.
>
>>From the TZ string you get all the information you need to construct a 
>valid time stamp. It gives you two literal strings, one with the name 
>of the time zone, the second (optional) with the name of the time zone 
>*with* DST, but it always possible to use the name of the time with 
>the addition "DST" - "(MET DST)", for instance, for "Middle European 
>Time plus DST". Other values you get from the TZ string are: GMT 
>offset, DST offset, the Julian days in the year, or the weekdays of 
>particular weeks of particular months that mark beginning and end of 
>the DST period, plus the exact hour of the day the transition occurs 
>(there are default values for that). From that information you can 
>compute the dates.
>
>It is important to keep in mind, first, that in the TZ convention 
>negative offsets are for positions East of zero longitude (Greenwich), 
>and positive values are for positions west of zero longitude, while 
>in the time stamp used in Internet messages it is the other way round. 
>So
>
>MET-1
>
>is for Middle European Time, one hour East of Greenwich (you have to 
>*add* the GMT offset to get GMT), while this same position is 
>indicated in Internet messages with
>
>+0100 (MET)
>
>(the tag is optional).
>
>Now for computing the DST begin and end times. I'll broadline outline 
>a possible strategy in C. time_t now = time(NULL); will give you the 
>current time, and with struct *tm = localtime(&now); you get the year 
>you're in. You can go back to 00:00:00 hours of January 1 of that year 
>by filling in a second struct tm with the appropriate values and apply 
>mktime(struct tm*) to it. Test if the year is a leap year (divisible 
>by 4 and not by 100, or divisible by 400). If begin and end days are 
>given in Julian year days, it's a piece of cake, because you know 
>exactly how many days (=24*60*60 seconds) you have to jump forward. If 
>the numbers of the months and the weeks and the weekdays are given, 
>the situation is more complicated, but not really difficult. It 
>requires a little arithmetic to compute the exact day in the year the 
>DST period starts and ends, but no operations beyond adding and 
>subtracting are required. (For example, to go to a certain weekday in 
>the last week of a month, jump to the next month, and keep on 
>subtracting 24*60*60 seconds until you arrive in the previous month 
>(test with localtime()), then keep on subtracting until you get to 
>the required weekday (again, test with localtime()). Etc.)
>
>Now you have three values, in seconds, three longs, which mark the 
>current time, plus beginning and end of the DST period, so you know 
>exactly where you are.
>
>Note that there is always a `grey' zone, the length of the DST offset, 
>at the end of the period, when you can't be certain where you are, 
>since the internal clock might have been set back to `normal time' 
>already. If the clock is still set to DST time, the test is now<end, 
>while if the clock has already been set back to normal time, the test 
>is now<(end-dst_offset). This can only be remedied by having recourse 
>to an external variable which tells you if the clock has already been 
>adjusted back to `winter time'.
>
>>Hmm, I don't know why you are reacting this way.
>
>I reacted that way because it seemed to me you didn't take my 
>criticism seriously. To both my remark about the inclusion of a 
>reference in mail headers, and my criticism of your handling of DST 
>information you reacted with a mental shrug of the shoulders. Like: 
>`Who cares?'. I feel that is the wrong attitude. It is precision and 
>care for detail which distinguishes (among other things) the `serious' 
>programmer from the careless amateur. And we don't like careless 
>amateurs in this group, do we?
>
>Good luck and feel free to ask for further clarification in case you 
>get stuck somewhere.
>
>Incidently: a few years ago I wrote an AUTO folder program which will 
>set your computer clock automatically to DST time and back. It's on 
>various ftp sites. Look for `dstint15.lzh' (it should be on cnam.fr, 
>in any case). Try it!
>
>-- 
> Jos den Bekker
><josdb@xs4all.nl>     http://www.xs4all.nl/~josdb
>                              -*-
>  "A man who hates himself has an enemy whom he can never escape."
>                                               - Norbert Wiener
>
>
>-------------- TZ.DOC -----------------
>
>  Setting the TZ environment string
>  
>   The value of the TZ environment variable should be set as follows
>   (spaces are for clarity only).
>   
>
>    std offset dst offset , rule
>
>The expanded format is as follows:
>
>    std offset[dst[offset][,start[/time],end[/time]]]
>
>std, dst
>    three or more letters that are the designation for the standard (std)
>    or summer (dst) time zone.  Only std is required.  If dst is omitted,
>    then summer time does not apply in this locale.  Upper- and lowercase
>    letters are allowed.  Any characters except for a leading colon (:),
>    digits, comma (,), minus (-), plus (+), and ASCII NUL (\0) are allowed.
>
>offset
>    indicates the value one must add to the local time to arrive at
>    Coordinated Universal Time (UTC).  The offset has the form:
>
>        hh[:mm[:ss]]
>
>    The minutes (mm) and seconds (ss) are optional.  The hour (hh) is
>    required and may be a single digit.  The offset following std is
>    required.  If no offset follows dst, summer time is assumed to be one
>    hour ahead of standard time.  One or more digits may be used; the value
>    is always interpreted as a decimal number.  The hour may be between 0
>    and 24, and the minutes (and seconds) - if present - between 0 and 59.
>    If preceded by a "-", the time zone will be east of the Prime Meridian;
>    otherwise it will be west (which may be indicated by an optional
>    preceding "+").
>
>rule
>    indicates when to change to and back from summer time.  The rule has the
>    form:
>
>        date/time,date/time
>
>    where the first date describes when the change from standard to summer
>    time occurs and the second date describes when the change back
>    happens.  Each time field describes when, in current local time, the
>    change to the other time is made.
>
>    The format of date may be one of the following:
>
>    Jn
>        The Julian day n (1 <= n <= 365).  Leap days are not counted.
>That is,
>        in all years - including leap years - February 28 is day 59 and March 1
>        is day 60.  It is impossible to explicitly refer to the occasional
>        February 29.
>
>    n
>        The zero-based Julian day (0 <= n <= 365).  Leap years are
>        counted, and it is possible to refer to February 29.
>
>    Mm.n.d
>        The d'th day (0 <= d <= 6) of week n of month m of the
>        year (1 <= n <= 5, 1 <= m <= 12, where week 5 means
>        "the last d day in month m" which may occur in the fourth or fifth
>        week).  Week 1 is the first week in which the d'th day occurs.
>        Day zero is Sunday.
>
>    The time has the same format as offset except that no leading sign ("+"
>    or "-") is allowed.  The default, if time is omitted, is 02:00:00.
>
>Some examples are:
>
>TZ=EST5EDT
>    Eastern Standard Time is 5 hours earlier than Coordinated Universal Time
>    (UTC).  Standard time and daylight saving time both apply to this
>    locale.  By default, Eastern Daylight Time (EDT) is one hour ahead of
>    standard time (i.e., EDT4).  Since it is not specified, daylight saving
>    time starts on the first Sunday of April at 2:00 A.M.  and ends on the
>    last Sunday of October at 2:00 A.M.  This is the default when the TZ
>    variable is not set.
>
>TZ=EST5EDT4,M4.1.0/02:00:00,M10.5.0/02:00:00
>    This is the full specification for the default when the TZ variable is
>    not set.  Eastern Standard Time is 5 hours earlier than Coordinated
>    Universal Time (UTC).  Standard time and daylight saving time both
>    apply to this locale.  Eastern Daylight Time (EDT) is one hour ahead of
>    standard time.  Daylight saving time starts on the first (1) Sunday (0)
>    of April (4) at 2:00 A.M.  and ends on the last (5) Sunday (0) of
>    October (10) at 2:00 A.M.
>
>TZ=PST8PDT
>    Pacific Standard Time is 8 hours earlier than Coordinated Universal Time
>    (UTC).  Standard time and daylight saving time both apply to this
>    locale.  By default, Pacific Daylight Time is one hour ahead of
>    standard time (i.e., PDT7).  Since it is not specified, daylight saving
>    time starts on the first Sunday of April at 2:00 A.M. and ends on the
>    last Sunday of October at 2:00 A.M.
>
>TZ=NST3:30NDT1:30
>    Newfoundland Standard Time is 3 and 1/2 hours earlier than Coordinated
>    Universal Time (UTC).  Standard time and daylight saving time both
>    apply to this locale.  Newfoundland Daylight Time is 1 and 1/2 hours
>    earlier than Coordinated Universal Time (UTC).
>
>TZ=CET-1
>    Central European Time is 1 hour later than Coordinated Universal Time
>    (UTC).  Daylight saving time does not apply in this locale.
>
>TZ=EST3EDT,M10.3.0/0,M.2.2.0/0
>    Belo Horizonte, Brasil, and most other metropolitan areas of
>    Brasil (including Brasilia).
>
>   Here are some further examples and an RFC page on the subject,
>   courtesy of Torkil Zachariassen <torkill@login.dknet.dk>
>
>
>TZ=CET-1DST,M3.5.0/2:00,M10.5.0/3:00
>    Denmark
>
>    CET  = Central European Time
>    -1   = one hour to the East of the Greenwich meridian,
>             about the Berlin time accepted by most Western
>             countries on the continent.
>    DST  = Americanese for "Daylight Saving Time"
>    M3   = Starts in the month of March
>    5    = at the last day number 0
>    0    = Sunday
>    2:00 = start time of the addition
>    M10  = Ending in the month of October
>    5.0  = again, on the fifth Sunday...
>    3:00 = at 3 in the morning, we return to CET-1.
>
>
>TZ=NZST-12NZDT,M10.1.0/2,M3.3.0/3
>    New Zealand
>
>        If some of your programs don't like the 4 letter abbreviations,
>        try 3 letter alternatives such as NST and, perhaps, NDT.
>
>   And here is a page from RFC822 on the subject of specifying dates and
>   times:
>
>
>     Standard for ARPA Internet Text Messages
>
>     5.  DATE AND TIME SPECIFICATION
>
>     5.1.  SYNTAX
>
>     date-time   =  [ day "," ] date time        ; dd mm yy
>                                                 ;  hh:mm:ss zzz
>
>     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
>                 /  "Fri"  / "Sat" /  "Sun"
>
>     date        =  1*2DIGIT month 2DIGIT        ; day month year
>                                                 ;  e.g. 20 Jun 82
>
>     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
>                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
>                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
>
>     time        =  hour zone                    ; ANSI and Military
>
>     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
>                                                 ; 00:00:00 - 23:59:59
>
>     zone        =  "UT"  / "GMT"                ; Universal Time
>                                                 ; North American : UT
>                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
>                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
>                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
>                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
>                 /  1ALPHA                       ; Military: Z = UT;
>                                                 ;  A:-1; (J not used)
>                                                 ;  M:-12; N:+1; Y:+12
>                 / ( ("+" / "-") 4DIGIT )        ; Local differential
>                                                 ;  hours+min. (HHMM)
>
>     5.2.  SEMANTICS
>
>          If included, day-of-week must be the day implied by the date
>     specification.
>
>          Time zone may be indicated in several ways.  "UT" is Univer-
>     sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
>     mitted as a reference to Universal Time.  The  military  standard
>     uses  a  single  character for each zone.  "Z" is Universal Time.
>     "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
>     lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
>     letter "J" is not used.  The other remaining two forms are  taken
>     from ANSI standard X3.51-1975.  One allows explicit indication of
>     the amount of offset from UT; the other uses  common  3-character
>     strings for indicating time zones in North America.
>
>---------------------------------------------------------------------------
>To unsubscribe from this list, e-mail Majordomo@spodden.zetnet.co.uk
>with the body of the message containing "unsubscribe Stik-Beta-Testers"
>---------------------------------------------------------------------------
>
>