Thanks,
Johnson Cheng
Definitely. Why the devil would you need that, anyway? If you want
to timestamp some log messages - syslogd will do that for you just
fine.
Local time is a bloody mess and rules for conversion are *nasty* -
they do not belong in the kernel.
Yes. You are right. Maybe it's not a good idea to use local time in linux
kernel.
But I have a project, linux kernel, need to get the current time(local
time) and display later.
Unfortunately I found nothing to do it.
Thanks,
Johnson Cheng
Store it in the kernel, extract it via /proc or /sys or ioctl() as appropriate,
do the converstion to localtime in userspace.
Chris
It is real an approach.
But why not do it in kernel because time string is more meaningful than
seconds or ticks.
I hope I can do it, too.
Thanks,
Johnson Cheng
Doubtless so. The kernel operates in UTC, as it was designed to do.
Why do you think you need to break that?
Write your driver to use UTC, and leave the pain of time zone handling
to the user space libraries.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/linuxy2k.html
"My experience as a member of the APB (Accounting Principles Board)
taught me many lessons. A major one was that most of us have a
natural tendency and an incredible talent for processing new facts in
such a way that our prior conclusions remain intact."
-- Charles Horngren
> In article <1e12973f.03041...@posting.google.com>,
> Johnso...@iei.com.tw <johnso...@iei.com.tw> wrote:
Unfortunately, you can't always avoid it. There are filesystems, for
example, that keep timestamps in local time.
DS
And what do you mean by "local time?" It's a multiuser system, after
all, and "local time" is all in the eyes of the user.
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxy2k.html
Rules of the Evil Overlord #148. "Before ridiculing my enemies for
wasting time on a device to stop me that couldn't possibly work, I
will first acquire a copy of the schematics and make sure that in fact
it couldn't possibly work." <http://www.eviloverlord.com/>
I know the kernel operates in UTC.
But there is an API, localtime(), converting time in seconds since
Epoch to local time.
How does it do it in kernel?
Thanks,
JohnsonCheng
It doesn't. localtime() is a userspace library routine.
What "localtime() API" are you talking about?
The localtime() function used on Linux is implemented in LIBC, which
is conspicuously NOT part of, nor available in, the kernel.
The nearest answer is
"It doesn't ``do it'' in the kernel."
Based on a strict definition where "Linux" is defined to be "the
kernel implemented by Linus Torvalds and cast of thousands," the API
you are talking about IS NOT PART OF LINUX. GLIBC is NOT PART OF THE
KERNEL. Linux ONLY knows about expressing times in terms of UTC; you
require other software, NOT PART OF LINUX, in order to express the
notion of a local time zone.
What you're trying to do can't be done, and shouldn't be.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www3.sympatico.ca/cbbrowne/linuxy2k.html
Why are cigarettes sold in gas stations when smoking is prohibited
there?
Have somebody ever thinking one thing about time convert formula?
localtime() API, implemented in LIBC, can't use in kernel,
but how does it do it in user mode?
I mean it must has its formula to convert the time in seconds to local time.
For example, 1 min = 60 sec, 1 hour = 60 min, 1 month = 28~31 days, etc.
So we just implement this formula in kernel, don't we?
Thanks,
Johnson Cheng
In fact the kernel has no notion of days, months or years even, it just
store the number of seconds past a specified zero point (00:00 1 Jan
1970 UTC).
Don't forget that the Western calendar isn't the only one. Storing the
time from the epoch is agnostic. How it's displayed is a userspace
issue.
Also converting from UTC to localtime is not a simple formula due to
messy daylight saving time rules. Worse still, governments change the
rules every now and then. First of all you don't want all that bloat in
the kernel. Secondly in userspace it's much less of a hassle to update.
And what, pray tell, would be the formula for, say it, "day in <year>
when <country> had switched to summer time"?
Userland deal with that mess by using a bunch of files with rules for
timezones. Take a look /usr/shar/zoneinfo - that's where they are.
And yes, it includes crap like "from '76 to '86 US switched to DST
on the last Sunday of April, since '87 it happens on the first one"
and a buttload of similar rules. What's more, such rules can be
added whenever politicians feel like that. No formulae for _that_
sort of events...
It's the timezone rules that really bite - if it was just "UTC+<constant>"
there would be no problem. That part is easy. The trouble begins when
you are need to find the offset from UTC on given date...