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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: why can't i turn off fast_time?
spellberg_robert wrote: > 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. > cd /etc cp /usr/share/zoneinfo/Etc/GMT+6 localtime Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: why can't i turn off fast_time?
On Tue, 27 Feb 2007, spellberg_robert wrote: greetings, all --- 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. The FreeBSD servers here are all UTC. To do this, all I did was made sure the BIOS clock was set to UTC and move the file /etc/localtime to /root (or somewhere outside /etc). At this time, the server doesn't use the localtime binary and defaults to UTC. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: why can't i turn off fast_time? [ success w/ post_mortem ]
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 "run
