time fetch error

[kmtdk]

well

is it a emu, or RHW ( if it is RHW, and you set the time in bios, it wil change for CMOS, and then it would be another)
if it is a emu, ensure that it is emuligating the current time ..
one tinny reminder
CMOS is aprocemently a few minuts behind ( on all my systems , also on read hardware )
but have you tried more than once ?? ( due to errors, and are you sure about the calculation when reading CMOS ?? ( from the raw data : 0x13 to the char's "13" )



KMT dk

[sawdust]

[quote="kmtdk"
but have you tried more than once ?? ( due to errors, and are you sure about the calculation when reading CMOS ?? ( from the raw data : 0x13 to the char's "13" )
KMT dk[/quote]

This runs on a real x86 pc. I tried it several times. Only the 'hour' does not seem to be correct. Or my interpretation may be wrong.

[pcmattman]

GMT time?

[mystran]

Does the century really even matter? We won't be going back any time soon, and it'll be 91 years and a couple of months before we wrap around again. Plenty of time for architectures to change.

[sawdust]

GMT time?

Seems like it. I live in (GMT-6), so the hour resembles that. But how do we know which timezone it is.

[Brendan]

Hi,

But how do we know which timezone it is.

You ask the user which time zone the RTC is set to when your OS is installed...

Note: Microsoft OSs typically use "local time" and adjust the RTC when daylight savings starts or ends. This means that for a dual-boot computer the other OS has no idea when Windows will adjust the RTC, or if Windows has adjusted it or not. This even stuffs things up when both OSs that are installed are Windows.

To avoid the problem all sane OSs try to set the RTC to UTC (but most OSs also allow the RTC to be set to anything else in a futile attempt to work around Microsoft's stupidity).

There is another option though - if possible, use NTP.

Of course even if you know that the RTC is set to UTC (or even if you do use NTP), you still need to ask the user which time zone they're in so you can figure out their local time.

However, in some cases (e.g. a server environment with remote clients using X or VNC or telnet or...) there's no guarantee that the users will be in the same time zone as the server. This means you may need to get the time from the RTC and use it to calculate UTC, and then use UTC to calculate "local time" on a per-client basis (and then provide some way for users to change their time zone - imagine a company server where sales people travel around the world and use SSH/X to login to the server remotely).


Cheers,

Brendan

[mystran]

...and all this timezone nonsense is only because stupid people (even more stupid than those that made Windows use localtime RTC) insist on having "local timezones" and "daylight savings" and all that nonsense.

It's not just computers. In the age of global communication, a lot of things would be made easier by everyone using same time (whether UTC or whatever) instead of constantly having to translate between different timezones, when communicating with people from different regions.

[Walling]

Have a look at TAI time. It is closely related to UTC, but it is continuous, whereas UTC have leap seconds inserted at "random" spots. The now dead Unununium OS project had an idea to use number of seconds after 2000-01-01T00:00:00 TAI as the internal date/time representation. If the user wants UTC you can always consult the leap seconds table and calculate that, or any other time zone for that matter. Two subsequent system time stamps would always be increasing.

[Steve the Pirate]

Hi,
I tried this one and got the following
sec= 18, min=1, hour=19, day= 14, month=10, year=8 century= 20
The actual time was 1:01 p.m, 18 seconds, 10/14/2008.
Why is hour=19 instead of 13 or 1 ?
TIA

Could be a timezone issue - it may be that the CMOS is set to GMT and your OS is converting it to your timezone (-6 hours)

[kmtdk]

from what i know
CMOS dont care about timezones ( Real time .... )
, so if you would like to talk about timezones, then it is GMT 0 ( from what i can see )

KMT dk