jv@mhres.mh.nl (Johan Vromans) (02/16/89)
In article <5698@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >The code that stores the timezone into the archive is in function >newdir() in file zooadd2.c: > > long gettz(); > direntry->tz = (uchar) (gettz() / (15 * 60)); /* seconds => 15-min units */ > >The gettz() function, found in bsd.c and sysv.c, must return the >timezone, in seconds west of GMT, as a long value. The above code >scales this value to to 15-minute units, casts the result to unsigned ^^^^^^^^ >char (which is typedef'd as uchar), and assigns it to direntry->tz. Flame On! Did you ever notice that the world does not stop at Greenwich? In other words: how about timezones that are EAST of GMT? WET = Western European Time equal to GMT MET = Middle European Time is GMT + 1 hour EET = Eastern European Time is GMT + 2 hours Another Flame On! Why do you adjust file times according to timezones? A file created at 12:00 GMT will have its time stamped 12:00 GMT whatever timezone it was created, archived or extracted. File times are stored internally relative to GMT. When stored this way, they should be retrieved this way. No need to change it. Both Flames Off! Apart from this problem, zoo appears to be a good program. -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (02/16/89)
In article <2884@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: ... | Another Flame On! | | Why do you adjust file times according to timezones? | A file created at 12:00 GMT will have its time stamped 12:00 GMT | whatever timezone it was created, archived or extracted. | File times are stored internally relative to GMT. When stored | this way, they should be retrieved this way. No need to change it. I don't understand this comment at all. Files are stored internally *where* as GMT? The only o/s which does this (as far as I know) is UNIX, and zoo runs on seven other o/s flavors. Am I missing something? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/17/89)
In article <2884@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) burns me to a crip with flames: >Did you ever notice that the world does not stop at Greenwich? >In other words: how about timezones that are EAST of GMT? The intent was to have all timezones represented as seconds west of GMT, up to a maximum of 24*60*60 seconds. So if you are 1 hour east of GMT, you are also 23 hours west of GMT. If there is a bug related to this, it probably involves a missing 1-day adjustment for sites east of GMT and west of the International Date Line. >File times [should be] stored internally relative to GMT. When stored >this way, they should be retrieved this way. No need to change it. The main problem with doing this is that not all operating systems maintain information about where they are relative to GMT. Most users don't even *know* how far they are from GMT. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu
gore@eecs.nwu.edu (Jacob Gore) (02/18/89)
/ comp.sources.bugs / dhesi@bsu-cs.UUCP (Rahul Dhesi) / Feb 16, 1989 / > >File times [should be] stored internally relative to GMT. When stored > >this way, they should be retrieved this way. No need to change it. > > The main problem with doing this is that not all operating systems > maintain information about where they are relative to GMT. Most users > don't even *know* how far they are from GMT. For those systems, is there any harm in pretending that they *are* on GMT? Jacob
fkk@altger.UUCP (Frank Kurt Kaefer) (02/19/89)
In article <13152@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: ~In article <2884@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: ~ ... ~| Another Flame On! ~| ~| Why do you adjust file times according to timezones? ~| A file created at 12:00 GMT will have its time stamped 12:00 GMT ~| whatever timezone it was created, archived or extracted. ~| File times are stored internally relative to GMT. When stored ~| this way, they should be retrieved this way. No need to change it. ~ ~ I don't understand this comment at all. Files are stored internally ~*where* as GMT? The only o/s which does this (as far as I know) is UNIX, ~and zoo runs on seven other o/s flavors. ~ ~ Am I missing something? I think you are pretty right. I have compiled ZOO without too much difficulty on OS-9/68k and it's running pretty well. But I just removed the timezone-stuff, because in OS-9 there is only the normal system time, although we also use TZ sometimes. Best regards, Frank Kaefer --- ...pyramid!tmpmbx!doitcr!stasys!fkk or fkk@altger ---
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/19/89)
In article <5930001@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes:
For [systems that do not maintain timezone information], is there
any harm in pretending that they *are* on GMT?
There is possible confusion if the same person has access to multiple
systems, some of which keep track of timezone and some of which don't.
Suppose you took an archive created on a UNIX system and transferred it
to your microcomputer running MS-DOS. If the archive created on UNIX
had timestamps recorded in GMT, the timestamps you would see on your
MS-DOS system would be off by the amount you are away from GMT.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edupeter@sugar.uu.net (Peter da Silva) (02/19/89)
In article <5930001@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes: > For those systems, is there any harm in pretending that they *are* on GMT? Sure. I zoo up an archive on my Amiga, and unzoo it on a UNIX box. All the times are now off. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
woods@gpu.utcs.toronto.edu (Greg Woods) (02/20/89)
In article <3453@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > In article <5930001@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes: > > For those systems, is there any harm in pretending that they *are* on GMT? > > Sure. I zoo up an archive on my Amiga, and unzoo it on a UNIX box. All the > times are now off. What would be a better solution, provided you absolutely must run your machine on local time (an idea I absolutely detest) or that you cannot replace enough of your O/S to fool yourself into thinking you have your machine running on GMT (for example, on a PC use the MKS toolkit which properly handles TZ)? I suggest that zoo archives (another thing I find very little use for) store GMT internally, and for those O/S's that can't manage to relate to the rest of the world, zoo may be compiled with a local time conversion factor built in. -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada
peter@sugar.uu.net (Peter da Silva) (02/20/89)
In article <1989Feb19.134220.29438@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > In article <3453@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > > In article <5930001@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes: > > > For those systems, is there any harm in pretending that they *are* on GMT? > > Sure. I zoo up an archive on my Amiga, and unzoo it on a UNIX box. All the > > times are now off. > What would be a better solution, provided you absolutely must run your > machine on local time ... Distasteful, but true fact: most operating systems other than UNIX do this. > I suggest that zoo archives (another thing I find very little use for) So why do you care? > store GMT internally, and for those O/S's that > can't manage to relate to the rest of the world, zoo may be compiled > with a local time conversion factor built in. Because zoo doesn't know what the local time is, but the UNIX system does have everythink it needs to convert between GMT and local time. QED. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
woods@gpu.utcs.toronto.edu (Greg Woods) (02/21/89)
In article <3465@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > In article <1989Feb19.134220.29438@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > > store GMT internally, and for those O/S's that > > can't manage to relate to the rest of the world, zoo may be compiled > > with a local time conversion factor built in. > > Because zoo doesn't know what the local time is, but the UNIX system does > have everythink it needs to convert between GMT and local time. QED. Let me say that another way: store file times in zoo archives as GMT. This will mean that zoo will be 100% compatible with Unix. For those machines that do not keep time interally as GMT, zoo can be compiled locally with a given time conversion constant such that it can adjust GMT times in archives to match local time. Zoo need not know what time it might be locally. This time conversion constant would be supplied by the person who installs zoo on a given system. It need not be compiled into the binary, in fact, but may come from an environment variable, a configuration file, or some other locally convenient place. Is there anything wrong with creating a Unix-like TZ entity on another type of system? -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/21/89)
In article <1989Feb20.183931.13918@gpu.utcs.toronto.edu> woods@gpu.utcs.UUCP (Greg Woods) writes: ...store file times in zoo archives as GMT...This time conversion constant would be supplied by the person who installs zoo on a given system. [could use an environment variable or a config file etc.] There are two problems with this. First, it forces the end user to go through an installation step. Second, it forces the code inside zoo to know about daylight savings algorithms. These are different all over the world and vary from time to time at the whim of legislators. Maintaining knowledge of daylight savings is easier to handle if you have a mainframe with a paid system administrator. It's harder to educate users of microcomputers about it. I don't want to force users to update their configuration file twice a year, or (alternatively) add information in the config file about when daylight savings time is in effect. Portable software ought to work correctly even if information about timezone is not available. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu
peter@sugar.uu.net (Peter da Silva) (02/21/89)
In article <1989Feb20.183931.13918@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > Let me say that another way: store file times in zoo archives as GMT. I understood it the first time. > This will mean that zoo will be 100% compatible with Unix. For those > machines that do not keep time interally as GMT, zoo can be compiled > locally with a given time conversion constant such that it can adjust > GMT times in archives to match local time. Zoo, in general, cannot be 'compiled locally'. The vast majority of Zoo users don't have compilers and don't *care* what time zone they're in. They just know they downloaded it from a BBS and it does a better job than ARC. People in the past have written programs that expected a TZ variable on non- UNIX systems. People just never bothered to set it. There are two useful alternatives: (1) Store local time and GMT, or (2) Store local time and timezone. These alternatives are equivalent, and the second takes less space. QED. Just because there was a bug in the implementation doesn't mean the design decision was wrong. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
gore@eecs.nwu.edu (Jacob Gore) (02/22/89)
/ comp.sources.bugs / peter@sugar.uu.net (Peter da Silva) / Feb 21, 1989 / > People in the past have written programs that expected a TZ variable on non- > UNIX systems. People just never bothered to set it. > > There are two useful alternatives: (1) Store local time and GMT, or (2) Store > local time and timezone. These alternatives are equivalent, and the second > takes less space. QED. I don't understand... If you store your local time and timezone, you know the timezone, right? How is storing (local_time, time_zone) different from storing (local_time - time_zone)? And the latter equals GMT. Jacob
mark@tsunami.megatek.uucp (Rocket J. Squirrel) (02/22/89)
So how about this: Store the local time in the archive, and on systems where you can find out the conversion to GMT store that also. Now, when transferring files from DOS (say) to DOS, the files AT LEAST have sensible times, even though they may in fact be off by a timezone or several. If a file is transferred from two machines that understand GMT, then a (trivial) bit of math gives you a true, corrected, universal time. -mark -- ucsd.edu!megatek!mark mark thompson "Tiger mutters the fighter pilot's prayer: `Oh shit.'" --
les@chinet.chi.il.us (Leslie Mikesell) (02/23/89)
In article <5798@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >There are two problems with this. First, it forces the end user to >go through an installation step. How about a command line option to adjust the file times by a specified amount? Then you could use local time on machines that don't know GMT and still be able to fix things if you want to install on a machine in another time zone or one that does know GMT. After all, if you don't know how much the time is off, then it probably doesn't really matter. Les Mikesell
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/23/89)
In article <7803@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >How about a command line option to adjust the file times by a specified >amount? Then you could use local time on machines that don't know GMT >and still be able to fix things if you want to install on a machine in >another time zone or one that does know GMT. After all, if you don't >know how much the time is off, then it probably doesn't really matter. Finally, a sensible comment about this. Folks, for interchange between sites if you desire to accurately convey the time information in the archive then you MUST establish some sort of standard. "Everybody use local time" will not do, unless some such command line option (or environment variable, etc.) is available and the user sets it up correctly. Even knowing what local time is recorded in the archive will not do, unless the receiving site knows the relevant time-zone rules for BOTH sites. An archive with UTC0 embedded in it has a universal (or at least planetary) meaning for its time stamps, which enables each site to deal only with its own time-zone problems independently of the other. As the man says, if you don't care if the time is off half a day or so, then you needn't convert between local time and UTC0 anyway. Archives maintained for use at a single site will be self-consistent in either case.
peter@ficc.uu.net (Peter da Silva) (02/23/89)
In article <5930003@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes: > I don't understand... If you store your local time and timezone, you know > the timezone, right? How is storing (local_time, time_zone) different from > storing (local_time - time_zone)? And the latter equals GMT. Because if you don't know the timezone you can store a token that indicates you don't know the timezone and the time is a local time. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` People have opinions. Companies have policy. And typos are my own business.
fritz@friday.UUCP (Fritz Whittington) (02/23/89)
In article <5798@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <1989Feb20.183931.13918@gpu.utcs.toronto.edu> woods@gpu.utcs.UUCP >(Greg Woods) writes: > ...store file times in zoo archives as GMT...This time conversion > constant would be supplied by the person who installs zoo on a given > system. [could use an environment variable or a config file etc.] > >There are two problems with this. First, it forces the end user to >go through an installation step. > >Second, it forces the code inside zoo to know about daylight savings >algorithms. . . . >Portable software ought to work correctly even if information about >timezone is not available. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi Software, portable or not, should be *able* to work "correctly" when given the proper inputs (or used in the proper manner). If I zoo files on a Unix system in Texas and un-zoo them on an MS-DOS machine in California, I would expect the software to at least be capable of restoring the correct creation times *if* I provide the time conversion information. (If I'm too ignorant to supply it by setting the proper environment variable, then it's *my* fault; if I do supply it and the software ignores it, the software is at fault.) The stuff about daylight time seems strange to me; MS-DOS users usually change their system clock to match the clock on the wall (if they care about time at all). Seems pretty trivial to change the 'offset from GMT' environment variable at the same time. -------end of purported useful information-------- The rest of this followup is dedicated to the stupidity of the current version of inews. It provides an excellent example of software that does not work "correctly" by refusing to even ask the news poster if he really is aware that he hasn't put in enough extra text to satisfy the ludicrous requirement that the amount of follow-up text be more than the amount of quoted text. The rumor that this requirement was added to the software specification for inews by a consortium of long-distance providers in order to increase their billings to Usenet machines is appealing, but probably untrue; I don't believe there *is* a software specification document for inews! ---- Fritz Whittington Texas Instruments, Incorporated I don't even claim these opinions myself! MS 3105 UUCP: killer!ernest!friday!fritz 8505 Forest Lane AT&T: (214)480-6302 Dallas, Texas 75243
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/24/89)
In article <9695@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: An archive with UTC0 embedded in it has a universal (or at least planetary) meaning for its time stamps, which enables each site to deal only with its own time-zone problems independently of the other. Note that the current scheme, of storing local time as well as timezone, implicitly stores both UTC and the local time of the user creating the archive. If UTC is not available, then it only stores the user's local time. Under the same conditions, a scheme storing only UTC fails completely. (I don't know the difference if any between UTC0 and UTC.) -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu
tneff@well.UUCP (Tom Neff) (02/24/89)
Peter da Silva's solution is best. ZOO should store local times plus a
timezone offset so that smart OS's like UNIX can convert to GMT for the
internal file timestamp. Even systems like MS-DOS which store times
locally, but which allow you to set TZ in your environment, would find
this useful, since ZOO could convert from Pacific time (for instance)
to MET when a European DOS user unpacks something assembled in the
Golden State.
A point I'm not sure has been clearly made here is that the status quo
is *wrong* even in the MS-DOS world by itself. When I unpack two ZOOs
dated the same day, I don't actually know which of the two is newer;
all I know is where Mickey's hands were on the wristwatch of each
author at the moment he built his file. This becomes troublesome
when data is exchanged electronically worldwide, which is of course
exactly one of ZOO's big justifications. Rahul went all out to conquer
stuff like filename syntax: this time thing ought to be a snap.
The other objection of the original poster is 100% correct. Offset
from GMT needs to be a signed quantity. Greenwich is not located at
the zero point of the world's day, but rather in the exact center! The
zero point is the International Date Line. Europe is most emphatically
*not* 23, 22 and 21 hours "behind" Greenwich; it is 1, 2, and 3 hours
*ahead*. (No place on Earth is more than 12 hours behind Greenwich.)
It should be trivial to make an upward compatible change to ZOO to
support the time offset as a signed quantity. Old "+23h" formats
would be silently translated to the new format.
ZOO is doing terrifically well as the binary archiver of choice on a
wide variety of platforms. The above is meant purely as constructive
criticism!
--
Tom Neff tneff@well.UUCP
or tneff@dasys1.UUCPjejones@mcrware.UUCP (James Jones) (03/03/89)
My favorite example is that of Australia. A friend tells me that one year, the end of DST was put off by one week by legislative fiat. Why? Well, HRH Queen Elizabeth II came to visit that year, and if DST ended at the canonical time, schoolchildren couldn't see her while it was still light outside. James Jones