mktime

[Robert Elz]

    Date:        Sun, 8 Feb 87 21:35:31 est
    From:        mark at cbpavo.mis.oh.att.com (Mark Horton)
    Message-ID:  <8702090235.AA06267 at cbpavo.MIS.OH.ATT.COM>

    I gather you don't read ISO standards or RFC's 822 or 850.

    The ISO standards have you say "+hhmm", e.g. +1030 or -0500.  822 and 850
    let you say EST or PDT or whatever for the USA timezones, but recognizing
    that this convention doesn't extend outside the USA, require that the
    explicit zone offset be used for other zones.

Yes, I'm quite aware of this.  But as I said, this is a fairly
specialized use.  Most of the world's applications don't involve
parsing mail date headers, and similar.  The most common application
for something like mktime() is almost certainly going to be so
that users can enter dates in a whole variety of applications, for
all kinds of purposes.  Usually in such cases, you want the user to
be able to enter the least amount of information that makes sense
("Mar 1" or something) and have the program supply the rest.  Supplying
reasonable defaults for all the info that is needed for the initially
proposed mktime() is easy - supplying a default for the zone is VERY hard.
Yet, that is what your proposal required.  Before calling mktime()
the process would need to put something in the offset field(s) for
mktime to use.  Sure, if you want to invert GMT that's easy, but I
submit that's also not a common case (even in the UK).

Note, I'm not arguing that the ability to convert a time, and specify
the zone offset is not useful, and even necessary, it just shouldn't
be mandatory.

However, given that there need to be two different calls to achieve
these two different purposes, it seems as if it would be better to
be to make the "offset" an arg to the call that needs it, rather
than using the field in the struct tm.  This is just a matter of taste.

    Some applications will have a default time zone (the local one), others
    will default to UT.  But with a struct tm that was generated by gmtime
    or localtime; we should expect that these routines filled in the
    appropriate value.  If we got a date string from another machine (mail,
    news, network transaction) the time zone should be extracted from it.

I'm sure that there are applications where its useful to convert
a time_t to a tm and then convert it back to a time_t again, though
just now I can't think of one.  Most applications for mktime() are
going to be where the tm has been filled in from a time in text form,
something typed by a user, parsing ctime() output from some other
process, etc, and NONE of these is likely to supply useful zone
information.  Ctime() output may have been augmented by the zone name,
but that's useless except in wierd special cases like rfc822 headers
where its arbitrarily constrained by some rule like "only the US has
abbreviations worth considering".

    I'm sorry, but given a choice between a well defined ISO standard and a
    egocentric UNIX implementation, I don't see any excuse for violating the
    ISO standard.  Upward compatibility may require that external variables
    like timezone, TZ, or the ftime system call remain backwards for upward
    compatibility, but we're defining a new function here.  Hell, TZ and ftime
    aren't even to seconds resolution, anyway.

No, but the Sys V "extern long timezone" is.  Never mind, I will accept
having the offset in "east is positive" format if that's what everyone
feels is best.  I'm still a little concerned that it will cause bugs
because of the confusion, but not concerned enough to hold out for
keeping the old style.


Related to other mail recently .. I think one offset is enough in the
tm, to give this information, another to tell how much dst correction
has been applied isn't likely to be useful.  That's especially true
when considered against a location that might decide to have 1 hour dst
all year and 2 hours in summer, then later decide that this is a stupid
situation, and just advance its zone by an hour, and have 1 hour dst in
summer.  Nothing in the converted times (or gmt offsets) would be altered
by this rationalisation of naming (maybe the tm_isdst field), but if there
was a dst offset field it would need to be altered - anything using that
for anything productive would suddenly act differently, and that would seem
to be a bad idea.  If its not safe to use the data, then there doesn't
seem to be any point having it.  And yes, I also see no sensible use for
tm_isdst, except that one is too entrenched now to delete.

kre