本文介绍了time()sleep()和dst的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

嗨Ng,


i有一些(也许是简单的)问题。


1.系统时间睡觉()是否安全调整了吗?

2. DST-状态改变时睡觉()是否安全?


3.时间()返回值是否跳?

这个man-page表示它自1970年以来以utc *为单位返回秒,根据

系统时钟*

无论可能是什么。我希望它不要跳。


4.在哪种情况下它会改变+ -3600秒。

Linux:TZ-Env-变量,Ntpd,/ etc / localtime符号链接,通过日期调整

Win32:对话框系统 - 时区/自动调整

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

推荐答案



sleep()不是ISO C,所以它在这里是偏离主题的。

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



time()是关于主题的,但ISO C所说的唯一的事情就是

返回_a_表示时间。不是哪个,而不是具有哪些精确度,或其他任何东西。自1970年以来的秒数绝不是保证
。 time_t可能是一个unsigned long,格式为

TTTSSMMHHDDMMYYYY,适用于所有ISO C关注。


我相信你提出的问题与POSIX有关。如果是这样,请在

comp.unix.programmer中询问 - 但请在

发布前至少阅读_their_常见问题解答。


Richard

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




这些都是偏离主题的,但无论如何我都会回答。我的答案假设

a unix-like系统,可能根据我的
经验隐藏假设。

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.



编号如果时间向后调整,你可能会等待更长时间;如果

它向前调整,你可能会过早地醒来。我已经发生了这种情况,但在所有系统上可能并非如此。我不会

将这两种行为都视为安全。 - 最好的解决方案是

,以确保你的系统时间永远不会超过几美元


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



是的。在大多数现代系统上,系统时间以UTC保持,而DST

不会影响这一点。

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



仅在调整系统时间时。

Only when system time is adjusted.



通过日期调整,假设你调整了一个小时,这将是

做一件奇怪的事情。 Ntpd也会改变系统时钟,但它再次不太可能会在一小时内完成(NTP使用utc信息

因此不关心日光储蓄)

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)




time()是关于主题的,但ISO C所说的唯一的一点是它

返回_a_表示时间。不是哪个,而不是具有哪些精确度,或其他任何东西。自1970年以来的秒数绝不是保证
。 time_t可能是一个unsigned long,格式为

TTTSSMMHHDDMMYYYY,对于所有ISO C关注


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



与ISO相关的问题是 - 如果我在夏令时结束之前拨打时间()一次

,并在一小时后再次调用它,那么

difftime()会返回这两个值吗?是否保证为3600

[受时间和浮点错误影响]?

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


这篇关于time()sleep()和dst的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-05 11:30