Date: Wed, 31 Aug 94 17:25:07 GMT From: dolan AT fnoc DOT navy DOT mil (Kent Dolan) To: storner AT olicom DOT dk Subject: Re: New time routines Cc: djgpp AT sun DOT soe DOT clarkson DOT edu > My intention with the routine I posted was not to replace tzset(), but > rather to provide a means for being able to handle incomplete TZ > specifica- tions, even when the zoneinfo files are missing. As Greg > Roelofs has been telling us over the past days, you cannot expect > people who just want to use zip/unzip (or any other DJGPP-compiled > application) to install 300K of support files for DJGPP timezone > handling. That is way overstated. All that is really necessary is to include the instructions for creating a correct, fully specified TZ entry in your utilities' installation document, and then to have the utilities check that the TZ entry is parsable, and fail with a usage-like message that points the user back to the installation manual if it is not. MS-DOS users drown in environmental settings necessary to make products work, they wouldn't be offended if your utilities also required just one or two. And in fact, I think in particular the *zip utilities normally require the user to have put in an environmental variable for the temporary file anyway, so the user would already be involved in an autoexec.bat editing to get such products to work. If the djgpp code correctly handles time zone conversions <--> GMT, when given correct and complete Posix TZ entry information, that is sufficient. The rest of the problem is a documentation problem, not a programming problem, and it should be left to rest. The whole _purpose_ of standards is to let the programmer know when the task has been done sufficiently well, which is when its operation is in conformance with the standard. Making the task bulletproof against the efforts of users ignorant of the standard is excess effort spent in the wrong endeavor. However much harder and more unpleasant it is for programmers to write clear, unambiguous user documentation than to write code, nevertheless, it is there, and not in the code, that non-standard environment problems should be solved. How about if someone fetches and posts the complete description for the Posix TZ environmental variable so everyone can put a clearly written version of it into their product documentation, and we let the chief coder here, DJ, get on with more important work? Xanthian. -- Kent, the man from xanth. Kent Paul Dolan, CSC contractor at Fleet Numerical. (408) 656-4363. (Navy Unix email: ) (Navy cc:Mail email: ) (real world email: )