# A Proposed Nodelist flag indicating Online Times of a Node.

     | 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
                                2:442/600@fidonet.org

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

      Note
      ----

      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.

      Purpose
      -------

      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.

      Compatibility
      -------------

      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:

        Txy

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

       +------+----+  +------+----+  +------+----+  +------+----+  +------+----+
       |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
      TXH.

      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.

      Example
      -------

      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 ===
    /* TIMEFLAG.C
       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;

       flag[1]='A'+onhour;
       flag[2]='A'+offhour;

       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 ===
    /* INTFLAG.C
       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;

       times.on_min=0;
       times.off_min=0;

       times.on_hour=timeflag[1]-'A';
       if(times.on_hour>23) {
          times.on_hour -= 'a'-'A';
          times.on_min=30;
       }
       times.off_hour=timeflag[2]-'A';
       if(times.off_hour>23) {
          times.off_hour -= 'a'-'A';
          times.off_min=30;
       }
       return ×
    }
    === 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! :-)

      Summary
      -------

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

      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.

Go Back