why can't i turn off fast_time? [ success w/ post_mortem ]

[spellberg_robert]

greetings, all ---

i've been meaning to write a whole lot sooner.
too many non_maskable interrupts.

thank you, matthew.
thank you, duane.

as it eventuated,
   i spent all day for four days, mar_01_thu through 04_sun,
   working on this.
most of the results occurred thursday,
   but i wound up being snowed in on friday,
   most of which i spent hacking.
saturday and sunday were spent refining and
   exploring source for use in alternative solutions
   to be implemented "when i have some free time".



duane ---

the solution you proposed is perfect.
further, it is truly elegant.
i only spent about three minutes on it thursday night.
after all of the various things that i had tried,
   it is the approach that i chose to implement.



matthew ---

i recognized your name from other sources in my possession,
   so i was heartened to see you respond.
although your solution did not exactly address the problem as stated,
   it was sufficiently close to something that i had tried
   that i chose to work with it first.

i will summarize.

i selected a victim^H^H^H^H^H^Htest machine.
my /etc/localtime [ well, the last one i left there last summer ]
   was .../Etc/Europe/London.
my TZ was set to "gmt0".
i rebooted and verified that the mobo was on utc.

i removed TZ.
i copied Factory, London,
   New_York, Indianapolis, Chicago, Denver, Phoenix, Los_Angeles,
   UTC, GMT, GMT+5, GMT+6, GMT+7 and GMT+8 to /etc,
   giving them names that are substantially similar,
   but which start with "localtime." for the benefit of "ls -a l*".
i would reboot frequently to check the mobo clock and
   to set the date to march or june.
rebooting also let me verify the timestamps being logged, in real time,
   during startup and shutdown.
i think these use /etc/localtime but not TZ.
i stopped rebooting once i verified what date(1) did to the mobo clock.

i discovered that /bin/tcsh
   resets the timestamp "percent_escapes"
   for its prompt variable only at login,
   while date(1) checks on each invocation.
i believe this to be a major source of my confusion.
i believe another source was
   not making a distinction between "date" and "date -u"
   [ i thought i was in utc, but maybe i wasn't always ? ].
further, to me, utc is local time and the other zones are all remote time.
however, these routines think the user's zone time is local and
   utc is remote.
also, to me, chicago is london MINUS six.
einstein was right; it's all about one's frame_of_reference.

i did most of my testing with Chicago, GMT+6, GMT and UTC,
   with winter and summer dates.
once i was satisfied, i copied GMT+6 to a new file i named CST.
using vi, i changed the string to "CST" and the length to four.
it's a good thing the length wasn't ten [ hey, it's a kloodge ].
thoughtfully, vi added the "missing" newline at the end of the "line".
checking the source for localtime(3),
   i don't believe the extra byte will be a problem.
i'll fix this "when i have some free time".
while localtime(3) itself checks /etc/localtime,
   i get the idea to create a routine that will
   read other files in "localtime format",
   so that i can have utc, local standard time, local legal time and
   [ thanks to a messy formula in
       dershowitz and reingold, "calendrical calculations",
       cambridge press, 1997
   ]
   apparent solar time [ woo_hoo !!! ],
   all at the same time.

i hacked similar files for EST, MST and PST.
all of these have names beginning with "/etc/localtime.".
then, i "ln -f" to the file of interest.
later, looking at the link count,
   i can see immediately which file is /etc/localtime.
three examples of my naming convention
   [ i'm big on filename completion, e. g., "l*zm6" ]:
   /etc/localtime.m6_.usz.etc.gmt+6.zm6
   /etc/localtime.m6a.usz.america.chicago.zm6a
   /etc/localtime.m6h.cst.zm6h
"usz" is short for "usr/share/zoneinfo".
"h" is the hacked file.
"zm" is "zulu minus".
i also added a file "/etc/localtime.readme.r",
   wherein i explained all of this to myself.

for the record, i have stopped using TZ.
now i know how to do "localtime format" files,
   so i don't think i need it.
i never used tzsetup(8).

i confess that there --was-- some serendipity.
for example,
   about midway through thursday,
   the most productive question i asked myself was,
   "why is this off by seven hours when it should be off by five?".
if matthew had told me "GMT" instead of "GMT+6",
   i would have been +/- an hour around zero hours
   instead of being around six hours.
then, i would have chalked it up to being
   backwards instead of forwards
   instead of
   forwards instead of backwards
   [ or is it the other way around ? ].

i think the reason the existing documentation is insufficiently clear
   [ and i went through a lot of it ! ]
   is because the authors assume
   [ correctly, for the overwhelming majority of people ]
   that the user wants their timestamps in local legal time.
when an eccentric like me comes along wanting to do something unanticipated
   [ i don't set my clock ahead, the outside world starts "running early" ],
   it becomes a challenge.
perhaps, after creating all of these time_zone_history files,
   over however long a period of time it took,
   the various authors of these files decided they had done enough.
i can understand this;
   especially after i examined certain counties in indiana and kentucky
   that couldn't make up their minds
   [ maybe it depended on who won the election ].

i submit this much information on the off_chance that
   there exists another person in this world who does things this way and
   they try searching the mailing list archives.

no need to respond unless somebody wants to,
   in which case, please cc me as i am not subscribed to -questions.

again, i thank you.

rob