time() sleep() and dst

Discussion in 'C Programming' started by reppisch, Oct 27, 2006.

  1. reppisch

    reppisch Guest

    Hi Ng,

    i have some (maybe simple) questions.

    1. Is it safe to sleep() while system time is adjusted?
    2. Is it safe to sleep() while DST- State changes?

    3. Will time() returnvalues "jump"?
    The man-page says it returnes seconds since 1970 in utc *according to
    the system clock *
    whatever that may be. s I'd expect it not to jump.

    4. In which cases will it change +-3600 sec.
    Linux: TZ-Env-Variable,Ntpd,/etc/localtime symlink, Adjusting via date
    Win32: Dialog System-Timezone / Adjust automatically
    reppisch, Oct 27, 2006
    #1
    1. Advertising

  2. reppisch

    Richard Bos Guest

    reppisch <> wrote:

    > 1. Is it safe to sleep() while system time is adjusted?
    > 2. Is it safe to sleep() while DST- State changes?


    sleep() is not ISO C, so it's off-topic here.

    > 3. Will time() returnvalues "jump"?
    > The man-page says it returnes seconds since 1970 in utc *according to
    > the system clock *


    time() is on-topic, but the only thing ISO C says of it is that it
    returns _a_ representation of the time. Not which, not with which
    precision, or anything else. Seconds since 1970 are by no means
    guaranteed. time_t might be an unsigned long with the format
    TTTSSMMHHDDMMYYYY, for all ISO C cares.

    I believe the questions you ask are pertinent to POSIX. If so, ask in
    comp.unix.programmer - but do, please, at least read _their_ FAQ before
    posting.

    Richard
    Richard Bos, Oct 27, 2006
    #2
    1. Advertising

  3. reppisch

    Jordan Abel Guest

    2006-10-27 <ehsf5h$6cg$>,
    reppisch wrote:
    > Hi Ng,
    >
    > i have some (maybe simple) questions.


    These are off-topic, but I'll answer anyway. My answers assume
    a unix-like system and may have hidden assumptions based on my
    experience.

    > 1. Is it safe to sleep() while system time is adjusted?

    No. If time is adjusted backward you may end up waiting even longer; if
    it is adjusted forward you may end up waking up prematurely. I have had
    this happen, but it may not be the case on all systems. I would not
    characterize relying on either behavior as "safe" - the best solution is
    to make sure that your system time is never off by more than a few
    seconds

    > 2. Is it safe to sleep() while DST- State changes?

    Yes. System time is maintained in UTC on most modern systems, and DST
    will not affect this.

    > 3. Will time() returnvalues "jump"?

    Only when system time is adjusted.

    > The man-page says it returnes seconds since 1970 in utc *according to
    > the system clock *
    > whatever that may be. s I'd expect it not to jump.
    >
    > 4. In which cases will it change +-3600 sec.
    > Linux: TZ-Env-Variable,Ntpd,/etc/localtime symlink, Adjusting via date


    Adjusting via date, assuming you are adjusting by one hour, which would
    be an odd thing to do. Ntpd will also change the system clock, but it
    is, again, unlikely it will do so by one hour (NTP uses utc information
    and therefore does not care about daylight savings)
    Jordan Abel, Oct 27, 2006
    #3
  4. reppisch

    Jordan Abel Guest

    2006-10-27 <4all.nl>,
    Richard Bos wrote:
    >> 3. Will time() returnvalues "jump"?
    >> The man-page says it returnes seconds since 1970 in utc *according to
    >> the system clock *

    >
    > time() is on-topic, but the only thing ISO C says of it is that it
    > returns _a_ representation of the time. Not which, not with which
    > precision, or anything else. Seconds since 1970 are by no means
    > guaranteed. time_t might be an unsigned long with the format
    > TTTSSMMHHDDMMYYYY, for all ISO C cares


    A question which _is_ relevant to ISO would be - if I call time() once
    before daylight savings ends, and call it again an hour later, what will
    difftime() return on those two values? Is it guaranteed to be 3600
    [subject to time and floating point error]?
    Jordan Abel, Oct 27, 2006
    #4
  5. reppisch

    CBFalconer Guest

    Jordan Abel wrote:
    > Richard Bos wrote:
    >
    >>> 3. Will time() returnvalues "jump"?
    >>> The man-page says it returnes seconds since 1970 in utc
    >>> *according to the system clock *

    >>
    >> time() is on-topic, but the only thing ISO C says of it is that it
    >> returns _a_ representation of the time. Not which, not with which
    >> precision, or anything else. Seconds since 1970 are by no means
    >> guaranteed. time_t might be an unsigned long with the format
    >> TTTSSMMHHDDMMYYYY, for all ISO C cares

    >
    > A question which _is_ relevant to ISO would be - if I call time()
    > once before daylight savings ends, and call it again an hour later,
    > what will difftime() return on those two values? Is it guaranteed
    > to be 3600 [subject to time and floating point error]?


    What does the phrase "seconds since 1970 in utc" tell you?

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Oct 27, 2006
    #5
  6. reppisch

    CBFalconer Guest

    Jordan Abel wrote:
    > reppisch wrote:
    >>
    >> i have some (maybe simple) questions.

    >
    > These are off-topic, but I'll answer anyway. My answers assume
    > a unix-like system and may have hidden assumptions based on my
    > experience.


    Which you shouldn't, since erroneous answers will probably not be
    corrected here. Just refer the OP to the appropriate newsgroup.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Oct 27, 2006
    #6
  7. reppisch wrote:
    > Hi Ng,
    >
    > i have some (maybe simple) questions.
    >
    > 1. Is it safe to sleep() while system time is adjusted?
    > 2. Is it safe to sleep() while DST- State changes?
    >
    > 3. Will time() returnvalues "jump"?



    This hasnt much to do with the C standard, which tries to ignore
    real-time issues.

    but anyway:

    Your better OS's, and Unix, Linux, and Windows too, try to minimize the
    damage when the time is asked to change suddenly. They often slowly
    slew the time as to minimize the impact on programs that are expecting
    time to go forward and at a constant rate.

    On PC DOS, you'll see glitches around midnight where the time goes:

    11:59:59 Jan 1
    12:00:00 Jan 1
    12:00:01 Jan 1
    12:00:02 Jan 1
    12:00:03 Jan 1
    12:00:00 Jan 1
    12:00:00 Jan 2


    Oops...
    Ancient_Hacker, Oct 27, 2006
    #7
  8. reppisch

    Jordan Abel Guest

    2006-10-27 <>,
    CBFalconer wrote:
    > Jordan Abel wrote:
    >> Richard Bos wrote:
    >>>
    >>> time() is on-topic, but the only thing ISO C says of it is that it
    >>> returns _a_ representation of the time. Not which, not with which
    >>> precision, or anything else. Seconds since 1970 are by no means
    >>> guaranteed. time_t might be an unsigned long with the format
    >>> TTTSSMMHHDDMMYYYY, for all ISO C cares

    >>
    >> A question which _is_ relevant to ISO would be - if I call time()
    >> once before daylight savings ends, and call it again an hour later,
    >> what will difftime() return on those two values? Is it guaranteed
    >> to be 3600 [subject to time and floating point error]?

    >
    > What does the phrase "seconds since 1970 in utc" tell you?


    That he's got a platform-specific assumption. However, the issue of
    whether time()'s return value might "jump" (in terms of what time it
    represents and how it will compare to representations taken at other
    times) at the DST changeover does not depend on that assumption.

    Yes or no, is it possible for the return values from time(), taken an
    hour apart, to compare equal (or, if equality comparison is not
    meaningful, for difftime() to return zero)?
    Jordan Abel, Oct 27, 2006
    #8
  9. reppisch

    Flash Gordon Guest

    CBFalconer wrote:
    > Jordan Abel wrote:
    >> Richard Bos wrote:
    >>
    >>>> 3. Will time() returnvalues "jump"?
    >>>> The man-page says it returnes seconds since 1970 in utc
    >>>> *according to the system clock *
    >>> time() is on-topic, but the only thing ISO C says of it is that it
    >>> returns _a_ representation of the time. Not which, not with which
    >>> precision, or anything else. Seconds since 1970 are by no means
    >>> guaranteed. time_t might be an unsigned long with the format
    >>> TTTSSMMHHDDMMYYYY, for all ISO C cares

    >> A question which _is_ relevant to ISO would be - if I call time()
    >> once before daylight savings ends, and call it again an hour later,
    >> what will difftime() return on those two values? Is it guaranteed
    >> to be 3600 [subject to time and floating point error]?

    >
    > What does the phrase "seconds since 1970 in utc" tell you?


    That it is referring to a specific implementation rather than what the
    standard specifies. ;-)

    The standard says that time() returns an approximation to calendar time
    and difftime() returns the difference between two calendar times, so I
    think that it is implicit that difftime should work as expected on times
    straddling switches between daylight savings time (or summer time) and
    standard time. I.e. in your example it would return an approximation of
    3600 assuming neither call to time() returned (time_t)-1
    --
    Flash Gordon
    Flash Gordon, Oct 27, 2006
    #9
  10. reppisch

    Jordan Abel Guest

    2006-10-27 <-gordon.me.uk>,
    Flash Gordon wrote:
    > CBFalconer wrote:
    >> Jordan Abel wrote:
    >>> Richard Bos wrote:
    >>>
    >>>>> 3. Will time() returnvalues "jump"?
    >>>>> The man-page says it returnes seconds since 1970 in utc
    >>>>> *according to the system clock *
    >>>> time() is on-topic, but the only thing ISO C says of it is that it
    >>>> returns _a_ representation of the time. Not which, not with which
    >>>> precision, or anything else. Seconds since 1970 are by no means
    >>>> guaranteed. time_t might be an unsigned long with the format
    >>>> TTTSSMMHHDDMMYYYY, for all ISO C cares
    >>> A question which _is_ relevant to ISO would be - if I call time()
    >>> once before daylight savings ends, and call it again an hour later,
    >>> what will difftime() return on those two values? Is it guaranteed
    >>> to be 3600 [subject to time and floating point error]?

    >>
    >> What does the phrase "seconds since 1970 in utc" tell you?

    >
    > That it is referring to a specific implementation rather than what the
    > standard specifies. ;-)
    >
    > The standard says that time() returns an approximation to calendar time
    > and difftime() returns the difference between two calendar times, so I
    > think that it is implicit that difftime should work as expected on times
    > straddling switches between daylight savings time (or summer time) and
    > standard time. I.e. in your example it would return an approximation of
    > 3600 assuming neither call to time() returned (time_t)-1


    But is it required? and at this point we are going into pure
    standards-hypothetical territory (might be more on-topic for comp.std.c,
    not sure, since I _know_ what it will do on all platforms specifically
    mentioned thus far, and on those it will return 3600[ish]).

    And what's a "calendar time", anyway, my calendar only has dates.
    If it's analogous to a calendar date - well... if I take the difference
    between the calendar dates September 2 and September 14, the difference
    is 12 days, even if the days immediately follow one another in _real_
    time, as they did in 1752 in England and its colonies.
    Jordan Abel, Oct 27, 2006
    #10
  11. reppisch

    Eric Sosman Guest

    Jordan Abel wrote:
    > 2006-10-27 <4all.nl>,
    > Richard Bos wrote:
    >
    >>>3. Will time() returnvalues "jump"?
    >>>The man-page says it returnes seconds since 1970 in utc *according to
    >>>the system clock *

    >>
    >>time() is on-topic, but the only thing ISO C says of it is that it
    >>returns _a_ representation of the time. Not which, not with which
    >>precision, or anything else. Seconds since 1970 are by no means
    >>guaranteed. time_t might be an unsigned long with the format
    >>TTTSSMMHHDDMMYYYY, for all ISO C cares

    >
    >
    > A question which _is_ relevant to ISO would be - if I call time() once
    > before daylight savings ends, and call it again an hour later, what will
    > difftime() return on those two values? Is it guaranteed to be 3600
    > [subject to time and floating point error]?


    No. time() returns "the implementation's best approximation
    to the current calendar time" (7.24.2.3/3). There is no language
    in the Standard to say how accurate that approximation must be or
    how it is expressed. It might be considered unusual or even
    perverse, but a time() that reported the logarithm of the number
    of centifortnights since the most recent full Moon would (it seems
    to me) meet all the requirements of the Standard.

    In particular, there is no requirement that time_t be anchored
    to any kind of "universal" clock. It's perfectly all right for
    time() to report local statutory time, if that's what the system
    provides.

    --
    Eric Sosman
    lid
    Eric Sosman, Oct 28, 2006
    #11
  12. >> A question which _is_ relevant to ISO would be - if I call time()
    >> once before daylight savings ends, and call it again an hour later,
    >> what will difftime() return on those two values? Is it guaranteed
    >> to be 3600 [subject to time and floating point error]?

    >
    >What does the phrase "seconds since 1970 in utc" tell you?


    That someone is assuming a lot more than ISO C guarantees.
    Gordon Burditt, Oct 28, 2006
    #12
  13. reppisch

    CBFalconer Guest

    Gordon Burditt wrote:
    >
    >>> A question which _is_ relevant to ISO would be - if I call time()
    >>> once before daylight savings ends, and call it again an hour later,
    >>> what will difftime() return on those two values? Is it guaranteed
    >>> to be 3600 [subject to time and floating point error]?

    >
    >> What does the phrase "seconds since 1970 in utc" tell you?

    >
    > That someone is assuming a lot more than ISO C guarantees.


    Yes, after posting that I checked the standard, and there is no
    such phrase in it.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Oct 28, 2006
    #13
  14. On Fri, 27 Oct 2006 12:55:10 -0400, CBFalconer <>
    wrote:

    > Jordan Abel wrote:
    > > Richard Bos wrote:
    > >
    > >>> 3. Will time() returnvalues "jump"?
    > >>> The man-page says it returnes seconds since 1970 in utc
    > >>> *according to the system clock *

    <snip>
    > > A question which _is_ relevant to ISO would be - if I call time()
    > > once before daylight savings ends, and call it again an hour later,
    > > what will difftime() return on those two values? Is it guaranteed
    > > to be 3600 [subject to time and floating point error]?

    >
    > What does the phrase "seconds since 1970 in utc" tell you?


    POSIX but not C specifies UTC which does of course ignore
    daylight-savings aka summer changes. A more interesting question is
    before and after a leap second; true UTC includes them, but my
    understanding is POSIX is interpreted to exclude them.

    Although, you may not get many more chances to test this in anger or
    for it to make a difference; there is an apparently serious proposal
    to do away with leap seconds and just let UTC and TAI diverge until it
    gets up to minutes at least, which assuming no change in the Earth's
    recently observed behavior means for centuries, by which time all of
    us here will probably be dead and C likely forgotten.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Nov 20, 2006
    #14
  15. reppisch

    Random832 Guest

    2006-11-20 <>,
    Dave Thompson wrote:
    > On Fri, 27 Oct 2006 12:55:10 -0400, CBFalconer <>
    > wrote:
    >> What does the phrase "seconds since 1970 in utc" tell you?

    >
    > POSIX but not C specifies UTC which does of course ignore
    > daylight-savings aka summer changes. A more interesting question is
    > before and after a leap second; true UTC includes them, but my
    > understanding is POSIX is interpreted to exclude them.


    "In UTC" is interpreted to mean that it's a number which has 1 added or
    subtracted from it in the same way that the 'seconds' value of UTC does
    whenever there's a leap second. "True UTC" does not "include" them in
    the same sense that the alternative to the POSIX interpretation would;
    that would be TAI.
    Random832, Nov 20, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gonzalo Moreno
    Replies:
    2
    Views:
    12,420
  2. js
    Replies:
    1
    Views:
    790
  3. Roedy Green
    Replies:
    20
    Views:
    773
    Dr J R Stockton
    Oct 5, 2009
  4. Sam Roberts
    Replies:
    16
    Views:
    377
    Daniel Berger
    Feb 18, 2005
  5. Richard
    Replies:
    7
    Views:
    229
    Richard
    May 22, 2007
Loading...

Share This Page