Re: using mktime()

From: Al Bowers (lbowers21_at_cox.net)
Date: 02/21/05

  • Next message: Michael Mair: "Re: using mktime()" 
    Date: Mon, 21 Feb 2005 08:20:39 -0600

    Dave Thompson wrote:

    >>>
    >>>
    >>No. What the Standard says is that function mktime will bring
    >>all values into range. For example the range for struct tm member
    >>
    >>
    >
    >If the call is successful, yes. It (definitely) won't be if the
    >requested time is not representable in time_t, and it's not clear if
    >mktime() is allowed to fail in other cases that the implementor
    >decides are "too hard" -- the comments in the Olson public-domain
    >implementation imply to me that this might have happened.
    >
    >
    >
    Yes, the Standard does not specify anthing on the resulting values of
    the struct tm
    members should and and when an implement of function mktime decides that
    time is
    not representable. The values may be changed or unchanged, in part or
    in total.

    >>tm_sec is 0-59. If tm_sec has the value of say -69 the function
    >>mktime will bring tm_sec into range by subtracting 1 from tm_min.
    >>
    >>
    >
    >Actually tm_sec is 0-60 to allow for (positive) leap seconds, which
    >are rarely if ever implemented. That is, leap seconds actually happen
    >(for now, there has been discussion of eliminating them) but (most?) C
    >implementations (and systems) just treat them as transient errors.
    >The only people I've heard of actually using them are the ones for
    >whom they were designed -- astronomers and space navigators, and their
    >only contact to most ordinary people, GPS.
    >
    >
    >
    I believe the Standard specifies the representable range as 0-59. I do
    not recall any mention
    of leap seconds in the Standard. Perhaps you are referring to an
    implement that extends
    the Standard. Unfortumately, I will be away from headquarters for a
    week, and not have
    access to the Standard document. Please correct me if I am wrong.

    >Presumably you meant -60sec = -1min. -69sec = -2min leaving 51sec.
    >
    >
    >
    Yes, the result to bring tm_sec into range would be a decrease of 2 in
    tm_min and an
    increase of 120 in tm_sec to bring it's value in range at 51 (120-69).

    >>And on up the ladder, if necessary, until finally tm_mon and
    >>tm_year are determined. Then tm_wday and tm_yday components of the
    >>struct are set appropriately. I would think that a Standard C
    >>that would allow you to add to a time but make reducing it undefined
    >>would be unwise.
    >>
    >>
    >
    >
    >

    Al Bowers

  • Next message: Michael Mair: "Re: using mktime()"

    Relevant Pages

    • Re: Curious Question about Struct Padding
      ... C89-99 standard that prohibits the padding bytes within or after a ... struct from being suitable storage for another object. ... least in the C99 standard), although it would not be the first time I ... Using the member ...
      (comp.std.c)
    • Re: strict aliasing rules in ISO C, someone understands them ?
      ... > I try to understand strict aliasing rules that are in the C Standard. ... > Let's have two struct having different tag names, ... > struct s1 {int i;}; ... Accessing a member of the foreign structure type through the pointer ...
      (comp.lang.c)
    • Re: Curious Question about Struct Padding
      ... C89-99 standard that prohibits the padding bytes within or after a ... struct from being suitable storage for another object. ... least in the C99 standard), although it would not be the first time I ... Using the member ...
      (comp.std.c)
    • Re: Why is C Standard Code Example Invalid?
      ... JK> that a declaration of the complete type of the union is ... the safest bet is to take the standard at it's ... struct t1; ... "E.MOS", which would suggest that the implicit dereference occurs, but ...
      (comp.std.c)
    • Re: realloc() implicit free() ?
      ... block size as a request for one byte, and let the alignment mechanisms raise it as they will. ... is therefore suitably aligned for any type (`struct s' in particular), the value can be assigned to any type of pointer, and can then be used to access an object of that type. ... of the Standard can distort its meaning. ...
      (comp.lang.c)