why can't i turn off fast_time?



greetings, all ---

as long as folks are paying attention to
this whole time zone foolishness
foisted on us by congress
[ as if they don't have --real-- work to do; but, i digress ],
it seems to be a good time to inquire about my pet peeve.

please note:
this is the --one-- thing about freebsd
that --really--, and i mean --really--, hacks me off.

i have yet to figure out
how to turn off the warm_weather fast_time bug^h^h^hfeature.

i am outside chicago, so i am six hours earlier than london.

i choose to not observe fast_time any more than absolutely necessary.
twice a year,
these nimrods in washington actually expect me to
drop what i am doing and
go around everywhere and
change the clocks.
to put not too fine a point on it, i refuse.
[ quite by accident,
i discovered that this eliminates what i call "solar_shock".
now, when others grumble on monday
about the sun not being where it was on friday,
i laugh.
]

the first thing i did was to rtfm.
then, i selected a box on which to experiment.

the method that seems to work most successfully is
to tell the box it's in arizona.
this would be great if i were in, say, laramie, but,
i haven't moved there, yet.
so, it's a little irritating.

then, i thought i would be exceedingly clever
by creating the missing file
that would be logically found between arizona and indiana,
using those files as templates.
surprise, surprise, they're in binary; just like --windoze--.
having read eric raymond's "art of unix programming",
i agree completely that
configuration files should be in human_readable form,
not encoded in binary, mega_corp style.
i have put off playing with this approach.

last, i tried the environment variable trick,
both for the local zone and for utc
[ surely, i can make the box do everything in utc, i thought ].
sha_ZAM!!!
i thought i had struck the mother_lode.
everything was working just as i wanted.
i smiled smugly to myself.

euphoric,
i arose from my throne [ no, silly, the other one ],
outstretched my arm and commanded "shutdown -h now".

alas, logged messages were timestamped off by one hour.
i was crestfallen.

this suggests that the mobo clock is on utc [ or something ],
fbsd is kloodging this into local fast_time and, then,
the environment variable is re_kloodging the kloodge
to display what i want to see,
but shutdown doesn't honor the re_kloodge.
or some such.

this is the point where i gave up.

i recount the above from memory.
the last time i tried to get this right was about a year ago.

windoze gets this right
[ this is one of the few times when i prefer windoze;
think about this
].
i cam select a time_zone, then uncheck the "observe fast_time" box.
no problem.
but, my 'nix boxen have their own agenda.

i solved this by setting them to what displays as utc and
what produces the right epoch_offset,
then i calculate the correct timestamps myself in my apps.
i simply accept that my timestamps are right and
some of the system generated timestamps are wrong.
c'est la guerre.

------------------------------------------

i wouldn't bother writing except that congress decided to meddle,
so some really_smart_people are paying attention.

all i want is
to be able to set my boxes to utc, with no fast_time, and
to have my apps and all of the other apps agree on what the clock says,
at --all-- times.

it would be a plus if
there were binary files for the 4 contiguous us time_zones
[ 2 of these already exist ],
--if-- that's the trick to getting what i want.
[ i suspect that
it would be considered a plus by others elsewhere on the planet if
such files existed for all 25 hourly zones and
the several whose offset is not a multiple of 60 minutes.
unlike mowing the lawn,
this job well done would not have to be done again.
]

it would be a really big plus if
non_textual config files were eliminated, but
i suspect that this is a bigger project than
most folks have time for right now.
[ if there is interest,
since, at least, --i-- care about this,
perhaps i could take this on,
but i'm full_up for the next several months.
however,
it strikes me that this might make a useful project for
some one or more of my students.
any thoughts?
]

-----------------------------------

thanks for letting me inquire.

if anyone thinks this sufficiently worthy of
either positive or negative response,
please cc me as i am not subscribed to -questions.



rob spellberg
woodstock, illinois

_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Problems with the Timezone
    ... GMT-4 in solaris and even in windows has always work fine with GMT-4. ... zone designation, his hours/minutes/seconds were correct - but the ... system time, which should be UTC, was actually 8 hours off from UTC. ... # positive signs east of Greenwich. ...
    (comp.protocols.time.ntp)
  • Re: need help with timezone conversion (unexpected side effect of time.mktime ??)
    ... the latter operation, though. ... I can see that both timestamps could be ... Maybe asking for a conversion for a ... the zone data. ...
    (comp.lang.python)
  • Re: Daylight Savings Time bug? Experts requested
    ... The BIOS clock is likely set to local ... True -- a program can also request UTC time, ... If the timezone update has or has not been ... When the zone cannot be set correct then the time ...
    (microsoft.public.windows.server.general)
  • Re: NTP Public Services Project help - +1 hour setting
    ... he said these are windows servers. ... Internally, the system time in Windows 32 is kept in UTC, and I'm sure the ... Yes, the BIOS clock is kept in local time, presumably to help those system ... > filesystem timestamps actually stored on disk are in local time, ...
    (comp.protocols.time.ntp)
  • RE: Best practice for TOD clock
    ... returns the UTC time. ... local applications that log with local time) for one hour in the fall. ... duplicate timestamps if the timestamps are using UTC time. ... For IBM-MAIN subscribe / signoff / archive access instructions, ...
    (bit.listserv.ibm-main)