On Thu, 7 Feb 2002, David Douthitt wrote:
> I've been looking into the date and time set in an Oxygen system, and
> comparing to a Mandrake system.
>
> The confusion comes this way:
>
> * Hardware clock: set value
> * Hardware clock (hwclock): value displayed
Interesting comment on manpage:
--utc
--localtime
Indicates that the Hardware Clock is kept in Coordinated
Universal Time or local time, respectively. It is
your choice whether to keep your clock in UTC or local
time, but nothing in the clock tells which you've cho�
sen. So this option is how you give that information to
hwclock.
If you specify the wrong one of these options (or specify
neither and take a wrong default), both setting and
querying of the Hardware Clock will be messed up.
If you specify neither --utc nor --localtime , the default
is whichever was specified the last time hwclock was
used to set the clock (i.e. hwclock was successfully run
with the --set , --systohc , or --adjust options), as
recorded in the adjtime file. If the adjtime file doesn't
exist, the default is local time.
... particularly the last bit.
> * System clock: set value
> * System clock: value displayed
>
> ...and these interact with:
>
> * /etc/localtime
> * TZ
>
> It would also appear that the man page for asctime(2) is wrong, and
> that the variable timezone is NOT set as it says it is.
>
> It would also appear that:
>
> * hwclock does not shift the time read according to timezone; it just
> "stamps" the output with the given timezone
> * hwclock remembers how the RTC was set - thus, hwclock --show may
> report UTC, or it may report localtime...
>
> I'm also getting lost in functions:
>
> gettimeofday()
man gettimeofday says:
The use of the timezone struct is obsolete; the tz_dsttime field has
never been used under Linux - it has not been and will not be
supported by libc or glibc. Each and every occurrence of this field
in the kernel source (other than the declaration) is a bug.
> tzset()
This function seems ripe for, ah, "optimizations" if you are using
nonstandard C libraries, but I would hope it works.
> time()
This always returns UTC.
> localtime()
This _should_ always convert the output of time() to broken-down local
time.
>
> ...which ONE of these gets the timezone right?
The last one _should_.
>
> Then there's header files:
>
> #include <time.h>
ANSI C... not a bad option, but I don't know how well cut-down libraries
would support this.
> #include <linux/time.h>
unless you are coding in the kernel, all you should get out of this is
struct timespec... probably not what you want.
> #include <sys/time.h>
The zone-related definitions in this header are mostly obsolete, according
to the comments. However, I think some functions would be needed by
hwclock, so I don't know...
>
> *ALL* of these conflict....
>
> And it even appears that busybox date may be reporting the wrong
> time... sigh...
>
> I wrote my own time display program (tz) just for testing purposes -
> it calls all of the above functions. I'll try to put it up on in the
> development area with source code.
>
> My hypothesis are:
>
> * hwclock works differently than I thought
can't say.
> * there may be actual bugs in busybox date
I don't know... my v0.47pre seems to work.
> * I may be mixing up standard C functions, Linux kernel functions, and
> old obsolete Linux kernel functions
I am not sure why you are, though. Are all of these mixed up in the
code? Or is this just from strace logs?
> Someone give me an aspirin!
http://risse.tierranet.com/asprin/asprin.html
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
