确定实际经过的（挂钟）时间 [英] Determining actual elapsed (wall-clock) time
问题描述
我想确定实际字样。操作的经过时间
可以在时间更改期间以平台无关的方式进行（至少在Linux / Windows机器上）。
使用time.time（）似乎不合适，因为如果系统时钟，时间可能会突然向用户突然转发或向后跳转
重置，
或夏令时变化发生时。
使用time.clock（）似乎不适合在Linux上使用
在Windows上显得足够。 （我愿意假设没有人会重置
，无论QueryPerformanceCounter（）用于在Windows上返回time.clock（）值
。）
曾经有一个时间模块（根据
http://effbot.org/librarybook/timing。 htm ）可能会工作
（至少对于Unix），但它不是最新的Pythons。
我如有必要，可以处理包装。我不太关心
分辨率，虽然优于一秒钟会有用。
感谢您的任何建议。
-Peter
Peter Hansen< pe *** @ engcorp.com>写道：我想确定实际操作的经过时间可以在时间更改期间以平台无关的方式进行（至少在Linux / Windows机器上）。
使用time.time （）看起来不合适，因为如果系统时钟被重置，或者夏令时发生变化，时间可能会以用户的心血来潮向前或向后跳跃。
如果你得到UTC时间，夏令时没有输入等式。
如果重置系统时钟，你运气不好我不能认为
的任何与时间相关的API都不依赖于系统时钟作为
参考。如果系统时钟好，那么你就玩得开心。如果系统时钟糟透了，或者有变化，你就不会。
如果你关心时间，你希望你的系统时钟由NTP控制。
没有理由不这样做。
有什么理由你不能只使用系统时钟吗？我想如果你需要b $ b bb，你可以将你自己的NTP客户端蹒跚而行，这样可以保持网络时间独立于系统时钟。但这将是很多工作，而且很难想象这种努力是否合理。
Roy Smith写道：< blockquote class =post_quotes> Peter Hansen< pe *** @ engcorp.com>写道：
如果你得到UTC时间，夏令时不会进入等式。
当然......我没想到那种方法。关于绝对时间，我实际上并不关心
，所以至少DST案例应该可以正常工作。
如果你关心时间，你需要你的系统时钟由NTP控制。
没有理由不这样做。
我想只要NTP客户端设置确保时间
调整小于某个值X，就可以接受了。我会
必须研究如何设置Windows XP以防止用户自行更改时间，假设这是可能的。
你有什么理由不能使用系统时钟吗？
我期待使用系统（在Windows上运行）案例）
可能决定改变时间的用户，在某些情况下，
可能会使软件瘫痪。我没有想到
只是防止这种情况的可能性，但是如果我坚持安装NTP客户端
，他们应该没有问题。那个。
感谢您纠正我的思考过程...
-Peter
< blockquote> Peter Hansen< pe *** @ engcorp.com>写道：
我想只要设置NTP客户端以确保时间调整小于某个值X，就可以接受了。
NTP通常能够在几毫秒内保持局域网上的各种系统时钟，并且在几十毫秒之内来自GPS，WWV或类似国际时间参考的
互联网上的消息。
我将不得不研究如何设置Windows XP以防止用户<假设这是可能的，自行改变时间。
在像Windows这样的单用户系统上，你几乎不得不承担
用户可以做任何事情。他们可以关闭NTP，重置时钟，重启
系统，卸载你的软件，等等。
如果你能查看NTP是否正在运行它没有证明什么。
恶意和坚定的用户可以设置另一台机器作为NTP
服务器进行同步，甚至配置该机器来查看喜欢它
是一个stratum-1参考（即一个原子钟）。
在某些时候，你需要决定你是否信任系统管理员来
为您提供准确的系统时钟。如果你没有，并且你有一个准确的时间参考非常重要，那么你手上有一个有趣的工程问题。
I would like to determine the "actual" elapsed time of an operation
which could take place during a time change, in a platform-independent
manner (at least across Linux/Windows machines).
Using time.time() doesn''t appear to be suitable, since time might jump
forwards or backwards at the user''s whim, if the system clock is reset,
or when a daylight savings time change occurs.
Using time.clock() doesn''t appear to be suitable on Linux, though it
appears sufficient on Windows. (I''m willing to assume nobody will reset
whatever QueryPerformanceCounter() uses to return the time.clock() value
on Windows.)
There used to be a "timing" module (according to
http://effbot.org/librarybook/timing.htm) which would likely have worked
(for Unix at least), but it''s not in the latest Pythons.
I can deal with wraparounds if necessary. I''m not too concerned about
the resolution, though better than one second would be useful.
Thanks for any suggestions.
-Peter
Peter Hansen <pe***@engcorp.com> wrote:I would like to determine the "actual" elapsed time of an operation
which could take place during a time change, in a platform-independent
manner (at least across Linux/Windows machines).
Using time.time() doesn''t appear to be suitable, since time might jump
forwards or backwards at the user''s whim, if the system clock is reset,
or when a daylight savings time change occurs.
If you get the UTC time, daylight savings time doesn''t enter the equation.
If the system clock is reset, however, you''re out of luck. I can''t think
of any time-related API which doesn''t rely on the system clock as a
reference. If the system clock is good, you get good time. If the system
clock sucks, or changes, you don''t.
If you care about time, you want your system clock controlled by NTP.
There''s just no excuse not to.
Is there some reason you can''t just use the system clock? I suppose if you
had to, you could hobble together your own NTP client which keeps network
time independent of the system clock. But that would be a lot of work and
it''s hard to imagine the effort would be justified.
Roy Smith wrote:Peter Hansen <pe***@engcorp.com> wrote:
If you get the UTC time, daylight savings time doesn''t enter the equation.
Of course... I didn''t think of that approach. I don''t actually care
about absolute time, so this should work fine for at least the DST case.
If you care about time, you want your system clock controlled by NTP.
There''s just no excuse not to.
I guess as long as the NTP client is set up to ensure the time
adjustments are smaller than some value X, it would be acceptable. I''ll
have to look into how to set up Windows XP to prevent users from
changing the time on their own, assuming that''s possible.
Is there some reason you can''t just use the system clock?
I was anticipating use of the system (running on Windows in this case)
by users who might decide to change the time, and in certain cases that
could cripple the software. I hadn''t thought of the possibility of
simply preventing that, though if I insist on an NTP client being
installed, they shouldn''t have a problem with that.
Thanks for correcting my thought process...
-Peter
Peter Hansen <pe***@engcorp.com> wrote:I guess as long as the NTP client is set up to ensure the time
adjustments are smaller than some value X, it would be acceptable.
NTP is generally capable of keeping the various system clocks on a LAN
within a few ms of each other, and within a few 10''s of ms over the
Internet from GPS, WWV, or similar international time references.
I''ll have to look into how to set up Windows XP to prevent users from
changing the time on their own, assuming that''s possible.
On a single-user system like Windows, you pretty much have to assume the
user can do anything. They can turn off NTP, reset the clock, reboot the
system, uninstall your software, whatever.
If you could check to see that NTP is running, it doesn''t prove anything.
A malicious and determined user could set up another machine as a NTP
server to synch against, and even configure that machine to look like it
was a stratum-1 reference (i.e. an atomic clock).
At some point, you need to decide if you trust the system administrator to
supply you with an accurate system clock or not. If you don''t, and it''s
really important that you have an accurate time reference, you''ve got an
interesting engineering problem on your hands.
这篇关于确定实际经过的（挂钟）时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
