time() sleep() and dst

[reppisch]

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

 

[Richard Bos]

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

 

[Jordan Abel]

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]

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]?

 

[CBFalconer]

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?

 

[CBFalconer]

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.

 

[Ancient_Hacker]

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...

 

[Jordan Abel]

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)?

 

[Flash Gordon]

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

 

[Jordan Abel]

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.

 

[Eric Sosman]

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.

 

[Gordon Burditt]

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.

 

[CBFalconer]

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.

 

[Dave Thompson]

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

 

[Random832]

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.