Linux-kernel mailing list archive 1998-48,: Re: kernel knowledge of localtime (user-level implememntation)

# Re: kernel knowledge of localtime (user-level implememntation)

a sun (asun@saul5.u.washington.edu)
Mon, 30 Nov 1998 12:35:25 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Kris Karas: "OFFTOPIC [Re: SMP scalability: 8 -> 32 CPUs]"
- Previous message: Maciej W. Rozycki: "A repeatable Oops on Alpha/2.1.129 in scsi_proc_fill_inode"

> so, where do people think a timezone updater should be stuck? do
> people not like using the update daemon?

My machine has an rdate call in /etc/crontab to synchronise its time
to an atomic clock, and that call is set to run every three hours...

well, some random program you stick in crontab probably won't do. for
example, i use ntpd to keep all my clocks up-to-date. should we stick
it in there as well?

this issue has less to do with making sure your actual time is
accurate than making sure the kernel is in sync with the
timezone. sticking things in crontab only works if the
smbfs/fat/ncpfs/hfs users all put it in there (and it gets run pretty
often due to the chance that the timezone may be switched at any
time). the reason i'm fond of sticking a timezone updater in an
already always running daemon is because it's transparent to everybody
and it adds virtually no overhead.

anyways, i thought of the DST issue a little more and looked at how
the mac does it for hfs volumes. as i suspected, if you create a file
while DST is in effect and switch out of it, you end up with the file
created an hour in the future. how exciting.

the moral? local time is lame. attempting to pretend that it's really
utc in disguise (by assuming that local time == knowledge
of timezone) is doomed from the start.

-a
asun@u.washington.edu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Kris Karas: "OFFTOPIC [Re: SMP scalability: 8 -> 32 CPUs]"
- Previous message: Maciej W. Rozycki: "A repeatable Oops on Alpha/2.1.129 in scsi_proc_fill_inode"