| Document: FSC-0062
 | Version:  003
 | Date:     April 14, 1996
 | Author:   David J. Thomas

	  A Proposed Nodelist flag indicating Online Times of a Node
                               David J. Thomas

Status of this document:

     This FSC suggests a proposed protocol for the FidoNet(r) community,
     and requests discussion and suggestions for improvements.
     Distribution of this document is unlimited.

     Fido and FidoNet are registered marks of Tom Jennings and Fido


  Changes in content between the previous edition of this document, and this
  edition, are signified by bars (|) in the left margin, except where
  otherwise specified. I have changed the format of the document slightly to
  allow this. Where the format of the document has changed, but the actual
  text has not, bars are not present.


  There are currently several systems within FidoNet that offer file request
  or mail holding capabilities but are not continuously online. The only time
  during which these nodes can be contacted with reference to the nodelist is
  currently the Zone Mail Hour of the zone to which the systems belong. In
  theory, mailers can only use the zone mail hour(s) specified by the system
  in question to contact these nodes, which does not provide for any method
  of file requesting or calling for echomail that does not conflict with the
  Policy requirement that no echomail or files be transferred during the zone
  mail hour. This means that, in practice, if it is known that a particular
  node is online for more time than ZMH alone, but less than 24 hours a day,
  it is necessary to "kludge," or set this up as a special situation, in most
  mailers whenever a node has to be contacted a number of times, whether
  regularly or irregularly. The proposed flag would benefit the mailers in
  such a way as to provide for them the online times that the node is usually
  online for, thus cutting on the costs of calling a non-continuous mail
  node, only to find that it is not available; and also, hopefully preventing
  annoyance for a sysop whose mailer is being called whilst it is not online,
  for example in the case of a voice/data shared line.


  Since the current nodelist format is always being extended and nodelist
  processors look only for the flags that they know about, there are no
  expected compatibility problems with the suggestion outlined below.

  Format of additional nodelist flag

  The proposed nodelist flag has the following form:


  where x represents the startup time, and y the end time, in the following

   +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
   |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|  |Letter|Time|
   +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
   |   A  |0000|  |   F  |0500|  |   K  |1000|  |   P  |1500|  |   U  |2000|
   |   a  |0030|  |   f  |0530|  |   k  |1030|  |   p  |1530|  |   u  |2030|
   |   B  |0100|  |   G  |0600|  |   L  |1100|  |   Q  |1600|  |   V  |2100|
   |   b  |0130|  |   g  |0630|  |   l  |1130|  |   q  |1630|  |   v  |2130|
   |   C  |0200|  |   H  |0700|  |   M  |1200|  |   R  |1700|  |   W  |2200|
   |   c  |0230|  |   h  |0730|  |   m  |1230|  |   r  |1730|  |   w  |2230|
   |   D  |0300|  |   I  |0800|  |   N  |1300|  |   S  |1800|  |   X  |2300|
   |   d  |0330|  |   i  |0830|  |   n  |1330|  |   s  |1830|  |   x  |2330|
   |   E  |0400|  |   J  |0900|  |   O  |1400|  |   T  |1900|  |      |    |
   |   e  |0430|  |   j  |0930|  |   o  |1430|  |   t  |1930|  |      |    |
   +------+----+  +------+----+  +------+----+  +------+----+  +------+----+

| This flag is not intended to be a user flag. The flag is intended to provide
| information to computerised mailer processes, and is not easily read by
| human beings (although they can of course interpret the meaning of the
| flag); most mailers however do not attempt to interpret any information that
| is specified as a user flag, assuming that it is there for the benefit of
| human beings. Such mailers would not be able to make use of the information
| provided, which is the purpose of the flag.

| This flag is of course not specified in FTS-0005 at the time of writing, but
| this is not regarded by FidoNet as a problem because other flags in current
| use are not specified in FTS-0005.

  The case of the letter could be relevant. Whereas the case is currently not
  used by any flags in the document describing the current format of the
  nodelist, there exists the potential for the case of a letter to have
  relevant meaning. The case has to be correct for the CRC check calculation
  to prove correct, and this would be a good use for the case of the letter.
  If it is necessary to ignore the case, then the upper on-the-hour time
  should be used, i.e. the time that is listed after the upper-case letter.

| These times are expressed in UTC so that the flag is useful for systems all
  around the world, without the need for specific time zone information to be
  included in the nodelist. They do not adjust with daylight saving time for a
  similar reason. Note the section on daylight saving time for information
  about handling adjustments without changing the flag; this is important.

  Where necessary, the times can wrap around midnight, so for example, for a
| node that is online between the hours of 1800 and 0600 UTC, the flag TSG
  would be a valid indication of this time.

  This nodelist entry is not required by any node. It is supplementary to the
  #01, #02, #08, #09, #18, #20 flags and their !xx counterparts, though its
  meaning is different. It has been suggested to me about the possibility of
  an additional flag with the same meaning, but having a W as the first
  letter, indicating that the node is also available for all hours during
  weekends; however, I believe that the simple inclusion of the single flag
  indicated above will solve most problems, as it does indicate a period for
  non-CM nodes during which the node is available, which is all that is
  really required.

  Daylight saving time

  If a node changes online times with respect to UTC when daylight saving
  time becomes effective (which would be the case with most part time nodes),
  then this is to be taken into account when assigning this flag. An online
  times flag assigned to a node should not be altered for the specific
  purpose of adjusting due to daylight saving time, since large difference
  files (NODEDIFF's) would result if every node was allowed to do this, e.g.
  my node used to be online from 2300 to 0800 in local time, which in winter
| is UTC, but in the summer it becomes BST (British Summer Time). This is one
| hour ahead of UTC, and the corresponding availability times of my node
| during the summer period were 2200 to 0700 UTC. Therefore my online times
  flag would have indicated availability between the hours of 2300 and 0700
| UTC, the daily time period encompassing both times, so the flag would be

  Policy considerations

  This is a technical document. However, since the flag could make for an
  increase in the size of difference files, the author feels that the
  following guidelines should be adopted concerning the use of the flag.

  The online times flag does not replace the requirement for exclusivity of
  zone mail hour to be maintained. It is still annoying behaviour to have
  this flag and be unavailable during ZMH, just as it is annoying behaviour
  to have the CM (continuous mail) flag in one's entry, and disregard ZMH.

  Except for during ZMH, the sysop of a node using this flag finding that
  they need to take their mailer offline during the specified times to
  perform system maintenance, or for any other reason, would not be acting in
  an annoying manner to do so, unless the practice is found to be continuous,
  in which case the flag's times could be reduced, or the flag itself could
  be removed from their node entry.

  It should be noted that this flag is present for the benefit of mailers,
  not human beings. This means that the flag should be used only to indicate
  when a mailer is ready to receive calls. A system that uses a FidoNet-
  technology mailer in ZMH, and a human-access only system during other
  period(s) of the day that cannot receive mail, should not use this flag.
  This flag does not explicitly specify online times of a public access BBS,
  although for presumably most nodes with FidoNet-capable software, a public
  access BBS will be available during the times indicated.

  Where the flag is used, it should not often be changed. If a situation
  exists, for example, where a node uses a certain set of times during the
  first two weeks of a month, and a different set of times during the
  remainder period, the flag should be set to a time during each day of the
  month when the node is online. For example, if a node is online during
  1800-0800 for the first two weeks, and then during 2200-1000 for the
  remainder, the time flag should specify 2200-0800 only. If there is no such
  time (other than ZMH) then no flag should be used. Of course, any permanent
  changes, and any necessary reductions in the times, should be permitted at
  any time, but changes owing only to daylight saving time should certainly
  be expressly forbidden.

  File requests and user access are of course permitted during the online
  times indicated (except ZMH).

  The above list may seem rather frightening! Please note that they are
  guidelines rather than rules, unless FidoNet policy has included them as
  rules. In the vast majority of situations where a node is online for a
  fixed set of hours per day, the only thing to watch out for is that you get
  the daylight saving time period right. Then you don't have to worry about
  changing it at any time, except when your own online times change.


  With regard to time zones now; this is a complicated topic, so I wish to
  express an example. Imagine a node in Indiana, USA. It is online for the
  time period beginning 6 o'clock pm (1800) and ending 8 o'clock am (0800).
  This changes with daylight saving time, so the times expressed effectively
| become an hour earlier with respect to UTC during daylight saving time.

| Indiana is in the Central time zone, which is 6 hours behind UTC. Therefore,
| the online times in UTC can be expressed as 0000-1400 UTC during winter.
| During daylight saving time, however, the local time for Indiana is 5 hours
| behind UTC. The online times during this period are 0100-1500 UTC. The
| subset should be used, so that the online times flag for the node should
| indicate availability between 0100 and 1400 UTC, which is indicated
| by the flag TBO.

| (Thanks to a few people for pointing out that the previous example was in
| error; it assumed that Indiana was ahead of UTC, and not behind as is
| actually the case.)

  ANSI C routines to Calculate the Online Times Flag

  These were not provided in the first edition. Change bars will not be used
  here, since they would interfere with the syntax of the presented routines.

  The first program calculates the online times flag from the user's entry of
  the online times of a system, expressed in the local time zone, and the
  offset to UTC used by the user's country. It takes into account that the
  clock is put forward and back once a year by reducing the end time by one
  hour. The program should work on any platform, and has been tested.

=== start of code ===
   Calculates FSC-0062 time flag requirement from user input */

#include <stdio.h>

char *onlineflag(char *on, char *off, int utc_diff);

void main()
   char on[6], off[6]; int utc_diff;

   printf("\nPlease specify the time you come online [HH:MM]: ");
   scanf("%s", on);
   printf("\nPlease specify the time you come offline [HH:MM]: ");
   scanf("%s", off);
   printf("\nSpecify the difference between your local time zone in winter\n"
      "time and UTC (e.g. if your time zone is 6 hours behind UTC,\n"
      "enter 6): ");
   scanf("%d", &utc_diff);
   printf("\nYour online time flag is %s\n\n",
      onlineflag(on, off, utc_diff));

char *onlineflag(char *ontime, char *offtime, int utcdiff)
   int onhour, onmin, offhour, offmin;
   static char flag[4]="T  ";

   sscanf(ontime, "%d:%d", &onhour, &onmin);
   sscanf(offtime, "%d:%d", &offhour, &offmin);

   if(onmin>30) ++onhour;
   --offhour; /* to correct for daylight saving time */
   onhour = (onhour+24+utcdiff) % 24;
   offhour = (offhour+24+utcdiff) % 24;


   if(onmin>0 && onmin<31) flag[1] += 'a'-'A';
   if(offmin>29) flag[2] += 'a'-'A';

   return flag;
=== end of code ===

  The second program calculates the online times from the time flag, input
  as a pointer to char to the routine (this being of the format "Txy"). It
  returns a pointer to a structure which contains the on- and off-times in
  UTC. This is not a complete program; it is designed to be used by mailers
  to determine the valid online times. It has also been tested.

=== start of code ===
   Interprets online time flags and converts them to a set of UTC times */

struct TIMES {
   int on_hour;
   int on_min;
   int off_hour;
   int off_min;

struct TIMES *interpret_flag(char *time_flag);

struct TIMES *interpret_flag(char *timeflag)
   static struct TIMES times;


   if(times.on_hour>23) {
      times.on_hour -= 'a'-'A';
   if(times.off_hour>23) {
      times.off_hour -= 'a'-'A';
   return &times;
=== end of code ===

| The above routines can be copied and re-used as desired. I am now an
| amazing C programmer, but I still make no guarantees about them! :-)


  I believe this to be a neat and compact solution to, what is in my opinion,
  one of the gravest problems currently facing FidoNet. In FidoNet, most
  nodes are continuous mail, but it is important for the growth and
  popularity of FidoNet that non-CM nodes do not receive many mailer calls at
  times when they are off line. Users are bad enough in this respect. It is
  also useful for people wishing to contact hubs that are non-CM with mail
  for a downlink, and for people wishing to file request from a node that is
  not CM. There is no need for systems that are only online in zone mail hour
  to adopt this flag; also, there is no need for CM systems to adopt this

  Contacting the Author

  My board is now online continuously, except for periods of down time during
| which the board is maintained (few and far between now that Linux is used).
  Netmail contact is therefore possible at any time. I went CM because of a
  certain number of nodes calling at the wrong times, and also users. Users
  weren't too bad, but I dislike 0600 am wake-up calls, repeated at regular
  three-minute intervals for an hour, by mailers, rather intensely :-)

End of document.