Mail Archives: djgpp/1994/08/31/17:02:16
Jon Davis wrote:
> Forgive me for being naive. I am probably missing something very fundamental
> but I simply want the time routines to return the same value that the time
> and date commands give at the DOS prompt--- independent of environment
> variable settings and zoneinfo files. No other DOS compiler needs it and no
That's where you're wrong. stat() returns GMT, and if you want that GMT
time to be the "right GMT" time for your localtime-based DOS machine, you
have to set TZ. This is true of all DOS C compilers. If you're content
to pretend your machine's localtime is GMT, then you may or may not need
to play with TZ or zoneinfo or posixrules files. MSC assumes Pacific time,
djgpp assumes Eastern; but for most apps you can ignore that.
Kent Dolan wrote:
> 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.
As Eli and others have written, the posixrules file is all that is re-
quired for basic TZ settings to work, and I can live with distributing
that if need be. I have yet to see any details on where this file is
supposed to be installed or what environment variables are required, but
that's a minor issue.
What is most annoying at this point is that no other C compiler--including
the emx port of gcc, which is different from djgpp but obviously quite
similar in purpose--requires external files in order to work reasonably.
The others may not be 100% correct in every detail of their timezone handling,
but they do a pretty good approximation by default.
> 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.
No.
> 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.
The 7-character TZ setting is a de facto standard, regardless of whether
it is a Standard. How well or poorly a programmer supports such as standard
is, as always, up to the programmer. I simply don't think it's that hard
to make a better approximation in this case. As I noted in a message last
week, I think treating PST8PDT as PST8 is "more correct" than treating it
as GMT0. Neither is absolutely correct, but I would argue that there's a
continuum of rightness, not a boolean value.
However...as soon as 1.12m1 is released, my biggest problem will be solved
(consistency between stat() and tz*()), so I'm not going to fuss about this
anymore. I'm sure everyone will breathe a huge sigh of relief. :-) Btw,
special thanks to Henrik and Eli (and DJ, of course!) for their help.
Greg Roelofs
- Raw text -