Some comments on Fido and Time  15 Nov 85


Recent discussions of the problems (and proposed solutions) caused by time
zones, daylight savings time, and similar natural disasters have confused me in
many ways; and I fear that I am not alone.

I do not propose solutions.  This would be unwise without a surer grip on the
problems.  I do want to explore some of the needs and requirements so that I
might better understand the problems and evaluate proposed solutions.  Excuse
some of the formalities in the early steps, but I like a firm base.

0 - Who are the concerned parties?  I guess the following two consumers and
    two providers.
    o SYSOPs of the myriad Fidos out there in the world,
    o Local USERs of all those Fidos,
    o COORDINATORs of the network, and
    o AUTHORs of Fido software.

1 - What is their level of expertise?
    o SYSOPs vary radically, but _each and every one_ must install and use
      whatever it is that the providers provide.  Therefore, Fido time
      management for SYSOPs _must_ be addressed to the lowest level of
      computer understanding.  Low maintenance is the only thing which may
      be more important than ease of installation.
    o Local USERs are _amazingly_ naive.  They are the most fragile of beings
      and must not be jarred in any way lest they shatter.  I relearn this
      weekly.
    o COORDINATORs and AUTHORs seem to be professional level computer users
      if not professional implementors.  They should bear the brunt of any
      changes, confusion, or tricky design.

2 - What is the presumed Fido SYSOP's machine environment?
    o MSDOS machine (though one hopes that future ...)
    o Hardware clock (can one safely run a Net machine without one?)
    o Auto Answer/Dial modem
    o Exclusively Fido, part time Fido, or Fido in 'background'.

3 - What are the Fido and FidoNet environmental constraints?
    o All public nodes are known to all other nodes.  A random node may try to
      contact any other (unpredictable) node during any published net window.
    o There is no central knowledge or coordination of the event lists by
      which an individual Fido schedules, nor the routings set up for each
      mail schedule.
    o Fido schedules state a time, but not what zone that time is in.  It is
      currently wall clock time, but some suggest that it be UST.  Ben Baker
      suggests that an unused field of the scheduler record be used to indicate
      which time zone, and either be supported.
    Also interesting, but seeming irrelevant
    o There are privete nodes and nets of which the public net is unaware.
    o Routing is known by the net as opposed to the sender (a la Usenet)

4 - Who cares what time it is or when events occur?
    o Local USERs expect Fido to think the time is what their watches say.
      Commercial mail servers tend to speak of messages in terms of the
      sender's local time, though some speak of it as the readers local
      time.  None speak of it in some third (abstract) time.
    o FidoNet software has to to keep things synchronized worldwide.
    o MSDOS programs running between Fido runs or concurrently with Fido may
      be time of day dependent.  They often need correct wall clock time.
    o COORDINATORs want to speak in UST when talking globally, but in local
      time when speaking of a local net.  This is human and should be
      indulged if reasonably easy.  SYSOPs have this problem too.
    o SYSOPs often maintain text files describing their Fido's schedules so
      their users will be able to read about local system availability.

5 - When and why will the time or the timing of an event change?
    o Subsets of the FidoNet continually renegotiate topology and timing.
      Nets and chedules change.  This will probably continue for some time.
    o The wall clock is occasionally adjusted (usually by one hour).  These
      adjustments _tend_ to clump in time (Spring and Autumn) and by region.
    o The algorithms for determining if a particular Fido is to move on any
      particular day in a particular direction would require continued
      maintenance _if_ they were even determinable at one point in time.  This
      precludes total automation, period.
    o A Fido's hardware clock will be adjusted occasionally to correct for
      drift.
    o A Fido switches time zones; either by being moved, or the SYSOP decides
      to run on UST, or switches sides near an inter-time zone border.

5 - What information is required to adjust a local Fido?
    o What different times might  be adjusted?
      - The local time
      - The difference between local time and UST
      - A schedule negotiated with other Fidos
      - The time a local batch process is to be run
    o When the adjustment is to be done?
    o In what direction?
    o By what amount or to what value?
    o If adjusting to an absolute time, is it UST or local?


6 - What are the seeming problems?
    o Is a Fido thought of as on its local time, local standard time, or UST?
      For the moment, consider daylight/standard as equivalent to switching
      time zones.  It also helps, but is not necessary, to consider a Fido to
      be schizophrenic, and able to think in local and UST simultaneously.
    o When a SYSOP checks schedules for correctness, some events should be
      expressed in local time (Yell, local nets, ...) and some in UST (National
      Mail Hour [Public FidoNet Window?]).  Displaying in both forms and sort
      options may help here.
    o When the time is changed due to wall clock adjustment (moving or day/std,
      one must remember that scheduled events then divide into two sets:
      - Those which will stay at the same local time are not adjusted with
        respect to the local time.  They must be adjusted with respect to UST,
        in the same direction as the clock is adjusted. Yelling and local net
        schedules are likely to be in this category.
      - Events which stay at the same UST, must be adjusted with respect to the
        local time in the same direction as the clock is being adjusted.  The
        UHT of National Mail Hour does not move when a Fido is moved or when
        day/std changes are made.
    o Schedule renegotiations also fall into two classes: those expressed in
      local time and those expressed in UST.  In either case, it is only one
      schedule being affected, and it may be considered in relative isolation.
      Neither the wall clock nor UST are being moved.  One might like to move
      a group of schedules together.
    o When the hardware clock is corrected for drift, no schedules change, but
      Fido must be restarted or otherwise made aware of the change.


So, have I gotten it correct so far?  If so, I do not feel that the above
seriously hampers a solution.  What seems to be missing is
  o A clear metaphor for speaking locally in terms of the wall clock and
    globally in UST.
  o An intuitive classification of event types and adjustment types with respect
    to time.  To start we must differentiate between
    - Events which are 'on' (ie expressed in terms of) UST and are 'fixed'
    - Events which are on local time and move with the wall clock
    - Changing an event's (or group of events) time(s) do to external renego-
      tiations
    - Changing the local time due to Fido motion or day/std changes
    - Correcting clock drift.

Given clear differentiations here, what may be most useful is(are) a tool(s) for
  o Easily stating the event schedules and their external attributes (ie fixed
    [UST?] or local)
  o Easily moving events in time (either local or UST)
  o Inserting, deleting, and moving events within the event list (as Fido is
    sensitive to the order of the list)
  o Moving the wall clock and having the events stay correct by knowing which
    are fixed and which are movable
  o Viewing (and PREviewing) event schedules and changes in a way that exposes
    incorrect (ie. conflicting) schedules.  Moving local time may place movable
    events in conflict with UST fixed events

If I have still not drifted too far from reality, Let me propose:
  o Fido needs do nothing.  It runs on local time and everybody locally thinks
    in local time.
  o The only time they talk UST is when they mark an event as being a fixed UST
    event.  The Sysop must clearly differentiate between fixed and movable (with
    respect to UST, they are fixed with respect to local) events.
  o If Fido need not know fixed from movable, the differentiation could be made
    in an auxilliary file (eg. Ben's SCHED.REM).
  o A program such as Ben's EVENT.COM needs to
    - Differentiate the two event types
    - Provide for moving the system clock
    - Adjust appropriate events with or against clock motion

Well, by now I must have strayed sufficiently far or affronted enough folk to
quit for the evening.

randy
