System time & date thinks its in California not NYC
Gregg C Levine
people who are new here<)
Everytime I boot the system, his time & date readout reflect his origins. Do
you guys have any suggestions for reseting the OS clock to readout the
correct time, as it is where I am now?
Gregg C Levine mailto:hansol...@worldnet.att.net
"Use the Force, Luke." Obi-Wan Kenobi
"Trust in the Force, Luke, and wait." Obi-Wan Kenobi
"The Force will be with you. Always. " Obi-Wan Kenobi
"May the Force be with you." "And to you" Anonymous
Robert Elz
From: "Gregg C Levine" <hansol...@worldnet.att.net>
Message-ID: <NEBBILPGILJOMAFJGIPAE...@worldnet.att.net>
| Do you guys have any suggestions for reseting the OS clock to readout the
| correct time, as it is where I am now?
Change /etc/localtime - it is a symlink, point it to the timezone file
that represents wherever it is you are.
kre
Gregg C Levine
faster method, then using the stuff in zoneinfo's directory. Namely removing
the localtime file. Just thought you, and the rest of the members of
"Port-I386" would be interested.
--
Gregg C Levine mailto:hansol...@worldnet.att.net
"Use the Force, Luke." Obi-Wan Kenobi
"Trust in the Force, Luke, and wait." Obi-Wan Kenobi
"The Force will be with you. Always. " Obi-Wan Kenobi
"May the Force be with you." "And to you" Anonymous
der Mouse
> found a faster method, then using the stuff in zoneinfo's directory.
> Namely removing the localtime file.
Then your clock is wrong - or at least, your kernel is wrong for your
clock conventions. If /etc/localtime isn't there, the OS takes you to
be running in GMT. If that displays the correct local time, then your
hardware is set to local time but the kernel is assuming it's set to
GMT. (Almost certainly, at least; there are other conceivable
combinations, but that's really the only plausible one.) This won't
matter much, except for getting the timezone wrong in things like mail
headers, except that if you're in a location that does daylight time
you'll have to actually change your clock twice a year instead of the
usual thing (which is monotonic time, with the daylight time conversion
dealt with when converting to and from human-readable form). You will
also have trouble as soon as you try to exchange timestamps with the
rest of the world, such as if you ever get that machine on the net and
try to speak NTP....
der Mouse
mo...@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
der Mouse
> you'll find the clock is off whenever you boot into "the other" OS.
> This is because Windows sets the system clock to the local time,
> while NetBSD sets it to GMT. I would recommend running NTP under
> NetBSD, and something like d4time under Windows, so this will be
> corrected automatically at each boot.
IIRC there is a kernel compile option that allows the hardware clock to
be kept in local time by providing for an offset between hardware and
GMT. It'd mean changing kernels twice a year, as daylight time comes
and goes, but it may be of some use. If memory serves it's called
RTCOFFSET or RTC_OFFSET or some such.
> P.P.S. Discussions about setting the system time, and other similar
> "remedial/tutorial" questions should be sent to the netbsd-help
> mailing list instead of port-i386.
I'm sending this to port-i386 because my comments are fairly
port-specific (and indeed the problem I'm commenting on can't exist
except on machines that run both NetBSD and Windows, which AFAIK means
i386 and alpha.)
Jonathan Stone
In message <2000071503...@Twig.Rodents.Montreal.QC.CA>der Mouse writes
>Then your clock is wrong - or at least, your kernel is wrong for your
>clock conventions. If /etc/localtime isn't there, the OS takes you to
>be running in GMT. If that displays the correct local time, then your
>hardware is set to local time but the kernel is assuming it's set to
>GMT.
Didn't the poster from Jedi Knight sa he just switch this
machine from M$ to NetBSD? That'd fit the description perfectly.
As Mouse says, the right solution is to run your hardware clock in
GMT (or UTC). Anything else leads to confusion and disaster, let alone
the abomination of changing localtime.
[*] there seems to be some dispute whether they are more closely
related to gnomes, or maxwellian daemons.
Richard Rauch
port-i386...sorry for the cross post. (^&)
FWIW, I set up the RTC_OFFSET=360 in order to cope with a dual-booting PC.
I don't remember having to do anything special about dst. (Can't you also
tweak it manually via a sysctl if you don't want to change the kernel &
reboot?)
As far as I understand, it just adds N minutes to the clock as it's read.
It don't think that it interferes with DST.
On the other hand, I can't swear to it. (^& I'm so used to having my
watch an hour off half of the year that I don't let the higher order
functions of my brain worry about DST on the 'puter. (My machine is not
very tightly coupled to anything, so it wouldn't notice a 1 hour
variation.) If it _does_ interfere, maybe I should reboot the machine
again someday and set the BIOS clock back to GMT/UTC/whatever---my machine
no longer dual boots.
"I probably don't know what I'm talking about." --r...@rkr.kcnet.com
Geoff Wing
:(This continued to flare up on netbsd-help, but relates to a post on
:port-i386...sorry for the cross post. (^&)
:FWIW, I set up the RTC_OFFSET=360 in order to cope with a dual-booting PC.
:I don't remember having to do anything special about dst. (Can't you also
:tweak it manually via a sysctl if you don't want to change the kernel &
:reboot?)
IF you are dual booting with some Microsoft OS then you may want to use
RTC_OFFSET. Should you get into daylight saving you'll need to readjust:
either recompile with adjusted RTC_OFFSET or
% gdb --write /netbsd
(gdb) set rtc_offset=360
(gdb) quit
%
(and reboot)
Or what ever the appropriate minute offset is (instead of 360)
Regards,
--
Geoff Wing : <g...@pobox.com> Work URL: http://www.primenet.com.au/
Rxvt Stuff : <g...@rxvt.org> Ego URL : http://pobox.com/~gcw/
Zsh Stuff : <g...@zsh.org> Phone : (Australia) 0413 431 874
Jared D. McNeill
> ...
> I don't remember having to do anything special about dst. (Can't you also
> tweak it manually via a sysctl if you don't want to change the kernel &
> reboot?)
kern.rtc_offset seems to be read-only. Would it be possible to change
this?
Jared
der Mouse
>> change this?
> No, it's impossible. Because the rtc_offset is referred at the time
> when root partition is mounted, changing rtc_offset at /etc/rc is too
> late.
Too late for what? The clock may be wrong between mountroot and
ntpdate (or moral equivalent), but that's a comparatively small time,
and with rtc_offset set correctly, every time the software time of day
is rewritten to the hardware clock (meaning resettodr()), it'll get
done correctly....