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

a sun (asun@saul6.u.washington.edu)
Fri, 11 Dec 1998 18:44:03 -0800 (PST)


Make the wake-up semantics smarter... ie. if we know it's 37 seconds
away from a zone-change, sleep for 37 seconds or less. If we wake up
three times (10s each, so blah & sync), then the fourth time sleep
for only 7 seconds at most.

this would only work for DST switching. every other timezone switch is
ad hoc and totally unpredictable. even in the DST case, the relevant
tzfile is pretty opaque. as a result, parsing it isn't a sure thing
that you can depend upon.

10 seconds is a long time -- consider someone compiling a large
program (or kernel) on an affected FS when the zone change occurs.

10 seconds isn't that bad. you just end up with a bunch of files that
were created in the old time zone and a bunch of files created with
the new time zone. the kernel knowledge of the local timezone doesn't
have to be as good as the user level. in fact, other oses make that
statement as well. besides, no matter what you do, your files will
reflect a jump in time on a localtime-based fs.

Either that, or have the VFS know about time-offsets on a per mount
basis, and a pending time-offset update, so the VFS knows that it n
ticks, the offset will change too m or something -- it still probably
won't be race free, but hopefully close too it.

now, that's an ugly solution that actually doesn't do the right thing
when it should. furthermore, it doesn't really accomplish more than a
user-space solution does. time should do the correct thing if i decide
that i want to change timezones on a whim. think of people that take
their laptops with them on plane trips.

at the risk of repeating myself ad nauseum, here's my (horribly
offtopic) solution for people that complain about files being created
in the past/future:

_a dialogue on time_

user1) wow. my files on an smbfs/ncpfs/hfs/fat/vfat fs got
older/younger by an hour. what happened? did somebody screw
with them?

admin) when is it possible to experience 01:30:00 twice in the same
day?

user2) what kind of metaphysical mumbo-jumbo are you two talking
about? time always goes forward.

user1) ah. i forgot about daylight savings. i guess i really hadn't
thought of that as losing/gaining an hour. now, that i think
about it, i did lose/gain an hour of sleep last night.

user2) what about me? i just created a file in japan. when i copied
it to my computer in the us, it says that it was created
tomorrow. that's just impossible. how can i have something
from tomorrow today?

admin) you've just experienced the miracle of modern timezone travel
without the jet lag. just what day do you think it is in
japan?

user2) umm, i guess it is tomorrow. oh my. the mind reels.

user1) wait a minute. shouldn't the computer figure all of that out
and make it impossible for files to change dates like that?

admin) if you were using a filesystem that used a single reference
timezone, that would be the case. however, you're using a
filesystem that treats time like a simple watch.

user2) what do you mean?

admin) let's imagine that you want to record the dates and times in
which you did things. you have the following choices:
1) you use your watch and just put down the date and time.
2) you decide to jot down the timezone as well.
3) you decide to jot down the date using UTC as your
reference. you make a note that you're using UTC.

now, through the wonders of modern technology, you post your
daily routine on the web for all to read and enjoy. later, you
decide to ask your faithful fans what they were doing when you
were doing x ...

user2) get to the point.

user1) wait a minute. i see what's happening here. using #3 allows
everybody to instantly convert, so they know when you were
actually doing what. you can do the same thing with #2, but it
requires them figuring out when daylight savings goes into/out
of effect in your timezone. with #1, they're SOL and have no
idea when you really did things unless they happen to know
where you live. even then, they don't know whether or not you
recorded things in different timezones.

admin) yep. ncpfs/smbfs/fat/hfs are like #1 while ext2/nfs/afp/ufs
are like #3. filesystems like #2 don't really exist because
they have to do more work than #3 for the same benefit.

with filesystems like #1, you could take a virtual trip around
the world and create files with creation dates that span a 24
hour period in a few minutes. someone else looking at those
files couldn't tell if you actually had created those files in
the same timezone or not.

user2) well, why didn't you just say that in the beginning?
sheesh. so, why don't we just pretend that all the #1
filesystems are like #3? wouldn't that make everybody happy?

user1) wait a second. i move disks back and forth between my pc/mac
and my linux machine all the time. i don't want dates to go
jumping all over the place when i switch machines.

admin) precisely.

-a

-
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/