163 lines
8.7 KiB
Plaintext
163 lines
8.7 KiB
Plaintext
|
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
|