zador-anthony@CS.YALE.EDU (anthony zador) (09/09/89)
How does the UNIX date command know the date? Is there some file that is updated? Must date be the same to all shells on a given machine, or can su selectively adjust the date for a given shell? If a machine A is the disk server for B, what determines the date-stamp for a file, A or B? If someone could answer these questions, or even point me to one step beyond the man page on date I'd appreciate it. Thanks, Tony Zador
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/09/89)
In article <72074@yale-celray.yale.UUCP> zador-anthony@CS.YALE.EDU (anthony zador) writes: > How does the UNIX date command know the date? It's maintained by the kernel and accessed via the time() system call. >Is there some file that is updated? No. >Must date be the same to all shells on a given machine, You can generally use the TZ environment variable to set the time zone that is applied when interpreting the kernel's time (which is maintained as UT, not local time). >If a machine A is the disk server for B, what determines >the date-stamp for a file, A or B? The kernel that owns the disk inode controls the time stamp.
cpcahil@virtech.UUCP (Conor P. Cahill) (09/09/89)
In article <72074@yale-celray.yale.UUCP>, zador-anthony@CS.YALE.EDU (anthony zador) writes: > > How does the UNIX date command know the date? It performs a time(2) system call which gets the current time in seconds (actually this is the count of seconds since Jan 1, 1970 12:00am GMT), the ctime(3) library call is then used to generate the date that we all know and love. > Is there some file that is updated? Nope. > Must date be the same to all shells on a given machine, Yup. > or can su selectively adjust the date for a given shell? Nope. > If a machine A is the disk server for B, what determines > the date-stamp for a file, A or B? Depends upon the software you are using for the server, but it probably is the time on the machine that the file is stored. RFS uses a mechanism where it determines the time difference between the two machines at the start of a connection and this difference is added/subtracted whenever time containing data about files is passed between the systems. This way the times will be consistently relative to each other and not corrupted by system clocks with largely different times. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
bzs@bu-cs.BU.EDU (Barry Shein) (09/09/89)
> How does the UNIX date command know the date? >Is there some file that is updated? >Must date be the same to all shells on a given machine, >or can su selectively adjust the date for a given shell? >If a machine A is the disk server for B, what determines >the date-stamp for a file, A or B? The date is stored in Unix as an integer measured in seconds since "the epoch", January 1 1970. Most systems these days use a finer granularity than seconds but when dates are being used seconds is all that count. This integer can be set by a privileged, system-wide syscall. On many systems it doesn't have to be set often (or ever) because the system has a small battery which keeps the time current even if the system is shut off. There is no provision for modifying the date for one shell. On many Unix systems you can set an environment variable TZ which does alter the timezone for some library calls but that doesn't really change the time, only the way it is presented; 10AM EST is the same time as 9AM CST. Depending on your system, look at the manual pages for time(3C or 2), gettimeofday(2), ctime(3) and timezone(3). The best way to run a piece of software who's license has expired is to trap the time() or gettimeofday() system call in the appropriate debugger :-) -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
bill@bilver.UUCP (Bill Vermillion) (09/11/89)
In article <1138@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: ->In article <72074@yale-celray.yale.UUCP>, zador-anthony@CS.YALE.EDU (anthony zador) writes: ->> ->> How does the UNIX date command know the date? -> ->It performs a time(2) system call which gets the current time in seconds ->(actually this is the count of seconds since Jan 1, 1970 12:00am GMT), the ->ctime(3) library call is then used to generate the date that we all know ->and love. -> ->> Is there some file that is updated? -> ->Nope. -> ->> Must date be the same to all shells on a given machine, -> ->Yup. Believe that answer should be nope. -> ->> or can su selectively adjust the date for a given shell? -> ->Nope. -> H How about Yup. That is the date is displable in several different time zones, but the machine time stays the same - UCT (nee GMT). I just checked. This machines variable for TZ is set as EST5EDT. All I did was spawn a sub-shell and do TZ=CST6CDT; export TZ. Then I did a date, and the machine thought I was in Texas (or somewhere in the Central zone). It realy has to be this way, as you want local time displayed in the time zone of the caller. It makes sense to set TZ variables in the shell if you have callers spanning time zones. If someone calls from CA at 9PM PDT, why should their time display as 1AM EST. Just set their local variable - the time stamp on all the files is correct - it's just the display that changes. It would also be very confusing to have file creation times displayed in the timezone of the machine, rather than the caller. I can see it would be very easy to delete the wrong files - based on time stamps that didn't display local time. Yech! bill -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!tarpit!bilver!bill : bill@bilver.UUCP
jon@jonlab.UUCP (Jon H. LaBadie) (09/12/89)
In article <1138@virtech.UUCP>, cpcahil@virtech.UUCP (Conor P. Cahill) writes: > In article <72074@yale-celray.yale.UUCP>, zador-anthony@CS.YALE.EDU (anthony zador) writes: > > How does the UNIX date command know the date? > It performs a time(2) system call which gets the current time in seconds > (actually this is the count of seconds since Jan 1, 1970 12:00am GMT), the > ctime(3) library call is then used to generate the date that we all know > and love. > > > Must date be the same to all shells on a given machine, > > Yup. > > > or can su selectively adjust the date for a given shell? > > Nope. One minor adjustment is possible. As ctime(3) must adjust the GMT system clock for the local timezone, a particlular instance of a shell could set the TZ environment variable to something other than the actual timezone. Some systems may also allow fractional offsets. Try: $ TZ=KST-12KDT ; date # Time in Korea $ TZ=Twi300000Lit ; date # Time in the Twilite Zone -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon
jc@minya.UUCP (John Chambers) (09/26/89)
In article <322@bilver.UUCP>, bill@bilver.UUCP (Bill Vermillion) writes: > In article <1138@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: > ->In article <72074@yale-celray.yale.UUCP>, zador-anthony@CS.YALE.EDU (anthony zador) writes: > ->> > ->> How does the UNIX date command know the date? > ->> Is there some file that is updated? > ->Nope. > ->> Must date be the same to all shells on a given machine, > ->Yup. > Believe that answer should be nope. > How about Yup. > That is the date is displable in several different time zones, but the machine > time stays the same - UCT (nee GMT). > > This machines variable for TZ is set as EST5EDT. All I did was spawn a > sub-shell and do TZ=CST6CDT; export TZ. > > Then I did a date, and the machine thought I was in Texas (or somewhere in the > Central zone). > It realy has to be this way, as you want local time displayed in the time zone > of the caller. It makes sense to set TZ variables in the shell if you have > callers spanning time zones. The trouble with this is that you've assumed rationality on the part of system builders, as well as consistency in all releases of Unix. Neither is true. Sys/V generally uses the TZ environment variable, which is a fairly rational approach to handling the problem. It still doesn't handle the variety of rules for changing between standard and dayligh-saving, but then, who knows how to do that in a multi-timezone/multi-national system? Unfortunately, Berkeley systems haven't generally adopted this approach. BSD systems still store the timezone in the kernel, and many programs use the kernel's idea of the timezone regardless of anything in the user's environment. Thus, if you have a Sun, you tend to find that everything is Pacific time until you configure the kernel to know your timezone. This can be done via adb, but it must be done. And I know from experience that much Sun software gives rather undesirable results when you are in a different timezone than the kernel. It's even more fun when you use systems that have tried to merge BSD and ATT systems (which includes Sun, and a lot of others). You find that some of the library programs use the TZ environment variable, while others ask the kernel. I worked recently on some Sequent machines, which support two "universes" with different libraries. Two users on the same machine could quite easily get different timestamps for the same file, depending on which universe they logged into, even with apparently the same search paths and environments and shells and all. It could be worse. Most VMS systems still keep their system clock in local time, and when networked across timezones, they have lots of confusion trying to figure out what time it is. You can get some very interesting misbehavior from such programs as "make" in such cases, when a file you just saved has a timestamp off by an hour. (It's especially fun to see a file get created in the future. ;-) I also recently tried using some network-management software from Bridge (now 3Com) that used ASCII timestamps, local time, and didn't include any indication of timezone. When we tried using it to manage systems scattered across several timezones, its behavior was quite entertaining. After a lot of good laughs, we threw up our hands and went on to something else. They even run on Unix systems (Suns, actually), but they haven't learned. You'd think by now that system programmers would understand why timestamps should be in UT/UCT/GMT, but I wouldn't go betting any large budgets on it. I also wouldn't make any assumptions about the portability of code that uses anything but the binary Unix time() value. And even that is frequently off by multiples of an hour in various machines on a network. -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
jc@minya.UUCP (John Chambers) (09/26/89)
> to trap the time() or gettimeofday() system call in the appropriate > debugger :-) > -- > -Barry Shein Hey, Barry, do you *have* to give away our secrets to the general public? I mean, this may be appropriate for comp.unix.wizards (though any true wizard would probably flame you for mentioning something so obvious), but shouldn't we keep such things out of newsgroups like comp.unix.questions? If the whole world learns about them, how are we wizards to earn a living? {;-} -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
chris@mimsy.UUCP (Chris Torek) (09/26/89)
In article <17@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Unfortunately, Berkeley systems haven't generally adopted this approach. >BSD systems still store the timezone in the kernel .... Not since 4.3BSD-tahoe: $ date Tue Sep 26 08:13:53 EDT 1989 $ TZ=Poland date Tue Sep 26 13:13:57 MET 1989 -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
snoopy@sopwith.UUCP (Snoopy) (09/27/89)
In article <17@minya.UUCP> jc@minya.UUCP (John Chambers) writes: |Unfortunately, Berkeley systems haven't generally adopted this approach. |BSD systems still store the timezone in the kernel, and many programs |use the kernel's idea of the timezone regardless of anything in the |user's environment. You want the system to have its own idea of the timezone, for things like uucp. You do not want uucp looking at the user's TZ. _____ /_____\ Snoopy /_______\ cse.ogc.edu!sopwith!snoopy |___| sun!nosun!qiclab!sopwith!snoopy |___| tektronix!tessi!illian!sopwith!snoopy
guy@auspex.auspex.com (Guy Harris) (09/28/89)
>Sys/V generally uses the TZ environment variable, which is a fairly >rational approach to handling the problem. It still doesn't handle >the variety of rules for changing between standard and dayligh-saving, >but then, who knows how to do that in a multi-timezone/multi-national >system? Arthur Olson and the rest of the Timezone Cabal do; it's a solved problem. Read the rules from a file, whose name is constructed from the value of TZ.... >Unfortunately, Berkeley systems haven't generally adopted this approach. >BSD systems still store the timezone in the kernel, and many programs >use the kernel's idea of the timezone regardless of anything in the >user's environment. 4.3-tahoe uses the Arthur Olson code, and programs built under 4.3-tahoe get the timezone from the TZ environment variable, if set, or from the "default" time zone file (the one with the link to it named "localtime"), if TZ is not set. No programs built under 4.3-tahoe should still be bothering to get the time zone stuff from the kernel; the only ones that should are ones that haven't been recompiled yet. >Thus, if you have a Sun, you tend to find that everything is Pacific >time until you configure the kernel to know your timezone. Assuming you're not running SunOS 4.0 or later, which also uses the Arthur Olson code; all programs built under SunOS 4.0 should use TZ if set, or use the "default" file if not. >This can be done via adb, Or by reconfiguring the kernel, which may be a bit less painful. (In SunOS 4.x, it's done automatically by "tzsetup", run at boot time, which looks at the default time zone file's data and tries to pick the value for the kernel that most closely matches it; this is done for the benefit of old binaries.) >It's even more fun when you use systems that have tried to merge BSD and >ATT systems (which includes Sun, and a lot of others). You find that some >of the library programs use the TZ environment variable, while others ask >the kernel. This is definitely a pain, but it's no longer true in SunOS 4.0, as noted. With any luck, other vendors will pick the Olson code up as well, and have all environments handle time zones in the same way; one vendor that has picked up the Olson code is AT&T, for S5R4....
guy@auspex.auspex.com (Guy Harris) (09/28/89)
>You want the system to have its own idea of the timezone, for things >like uucp. You do not want uucp looking at the user's TZ. The way this can be handled with the Arthur Olson time zone code is to have "uucico" and company ream TZ out of the environment ("uucico" is the only program that has to do this), so that it gets the default time zone; it doesn't require that the kernel have any notion of time zone whatsoever, just that there be a link named "localtime" to the appropriate default time zone file.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/28/89)
In article <2507@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >With any luck, other vendors will pick the Olson code up as well... I highly recommend it also. As Guy says, it makes this a "solved problem".
jc@minya.UUCP (John Chambers) (10/12/89)
In article <310@sopwith.UUCP>, snoopy@sopwith.UUCP (Snoopy) writes: > In article <17@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > > |Unfortunately, Berkeley systems haven't generally adopted this approach. > |BSD systems still store the timezone in the kernel, and many programs > |use the kernel's idea of the timezone regardless of anything in the > |user's environment. > > You want the system to have its own idea of the timezone, for things > like uucp. You do not want uucp looking at the user's TZ. I'm not sure I agree, but let's agree for argument's sake. It's still not necessary for uucp (i.e., /bin/uucp, and /usr/lib/uucp/uucico when triggered by uucp rather than cron) to get the timezone from the kernel. I've surrounded both of these programs with small scripts on several systems, so I could modify their environments. It's easy enough to rename them and create a script with the original name that sets the TZ environment variable, then execs the real program. I've also done this so I could keep extra records saying who was calling them when. This is especially useful for the mail command; you might consider a mail script that calls one or more mailers, and if they all fail, sends the mail to a nearby machine for routing. The extra layer is not a big enough overhead that anyone ever notices. -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying
les@chinet.chi.il.us (Leslie Mikesell) (10/12/89)
In article <35@minya.UUCP> jc@minya.UUCP (John Chambers) writes: [re: shell wrappers ] >This is especially useful for the mail command; you might consider >a mail script that calls one or more mailers, and if they all fail, >sends the mail to a nearby machine for routing. >not a big enough overhead that anyone ever notices. How do you convince the mailers to just exit with an error status if they can't deliver instead of generating dead.letter or bouncing back to the sender? Les Mikesell