比较两台机器上的日期时间刻度

发布于 2024-09-05 00:56:17 字数 143 浏览 2 评论 0原文

比较两台不同计算机上两个文件的两个 FileInfo.CreationTimeUtc.Ticks 来查看哪个版本更新是一个可行的选择 - 还是有更好的方法?

刻度是否取决于操作系统时间,或者它们实际上是过去某个固定日期的物理刻度?

Is it a viable option to compare two FileInfo.CreationTimeUtc.Ticks of two files on two different computers to see which version is newer - or is there a better way?

Do Ticks depend on OS time or are they really physical ticks from some fixed date in the past?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

抽个烟儿 2024-09-12 00:56:17

UTC 时间的目标是它是通用的 - 但两台计算机必须具有同步时钟才能适合比较时钟周期。例如,如果我们的两台计算机在同一时刻更新了文件(抛开相对论),它们仍然可以记录不同的时间 - 这不像计算机往往内置原子钟。

当然,它们可以与 NTP 等同步时间,使彼此非常接近。如果没有更多信息,很难说这是否足够适合您的使用。您还应该记住用户故意弄乱他们的系统时钟的可能性 - 这会给您的用例带来问题吗?

The aim of a UTC time is that it will be universal - but both computers would have to have synchronized clocks for it to be appropriate to just compare the ticks. For example, if both our computers updated a file at the exact same instant (relativity aside) they could still record different times - it's not like computers tend to come with atomic clocks built-in.

Of course, they can synchronize time with NTP etc to be pretty close to each other. Whether that's good enough for your uses is hard to say without more information. You should also bear in mind the possibility of users deliberately messing with their system clocks - could that cause a problem for your use case?

得不到的就毁灭 2024-09-12 00:56:17

Ticks 是否取决于操作系统时间?
来自某些固定的真正的物理蜱虫
过去的日期?

蜱几乎独立于操作系统。
如果我没记错的话,1 秒 = 10000000 个刻度。

因此,无论您在什么时间进行检查,从 Ticks 中获得的信息大约是从 TotalSeconds 中获得的信息的一千万倍。 (尽管显然它比 TotalSeconds 更准确。)
一个刻度基本上是您可以从 .NET 测量的最小时间单位。

至于 UTC,是的,它已经是你能得到的最好的了。如果您的应用程序运行的计算机上的系统时间足够准确,您就可以毫无问题地管理它。

基本上,文件更新越频繁,该信息就越不准确。如果有人在一秒钟内创建了该文件的两个版本,则所有系统时间必须精确同步才能获得良好的结果。
如果您每几分钟只有一次不同的版本,那么这对您来说就足够了。

Do Ticks depend on OS time or are they
really physical ticks from some fixed
date in the past?

Ticks are pretty much independent of the OS.
If I remember correctly, 1 second = 10000000 ticks.

So whatever time you are checking, what you get from Ticks is about ten million times what you get from TotalSeconds. (Although it is more accurate than TotalSeconds, obviously.)
A tick is basically the smallest unit of time that you can measure from .NET.

As of speaking about UTC, yes, it is as good as you can get. If the system time on the machine your app is running on is accurate enough, you'll manage with it without issue.

Basically, the more frequent updates there are of the files, the more inaccurate this will be. If someone creates two versions of the file in one second, all of the system times must be precisely synchronized to get a good result.
If you only have different versions once per several minutes, then it is very much good enough for you.

想念有你 2024-09-12 00:56:17

简短的回答是,不,这不是一个可行的解决方案,至少在理论上,任何事情都有可能发生的世界中。

计算机的时钟可能精确到十亿分之一秒,但问题不在于精确度,而在于两台计算机的时钟是否同步。

这是一个实验。看看你的手表,然后随机询问你周围的陌生人现在几点了。如果您的文件是在您查看手表时写入到您的计算机上的,并且在 1 秒前写入到您所询问的人的计算机上,那么您的比较是否会确定您的文件或他/她的文件较新?

现在,您的解决方案可能会起作用,假设:

  • 您不必比较毫秒或纳秒的不同时钟值
  • 相关计算机的时钟与某些公共源同步
    ** 或者至少设置为在您的不准确标准允许的情况下彼此尽可能接近

根据您的要求,我会认真考虑尝试找到一种不同的方式来确保您获得正确的值。

The short answer is that no, this is not a viable solution, at least not in the theoretical, anything-can-happen type of world.

The clock of a computer might be accurate to a billionth of a billionth of a second, but the problem isn't the accuracy, it's whether the clocks of the two computers are synchronized.

Here's an experiment. Look at your watch, then ask a random stranger around you what the time is. If your file was written to on your computer when you looked at the watch, and written to on the computer belonging to the person you're asking 1 second ago, would your comparison determine that your file or his/her file was newer?

Now, your solution might work, assuming that:

  • You're not going to have to compare milli- or nano-second different clock values
  • The clocks of the computers in question are synchronized against some common source
    ** or at the very least set to be as close to each other as your inaccuracy-criteria allows for

Depending on your requirements, I would seriously look at trying to find a different way of ensuring that you get the right value.

傲世九天 2024-09-12 00:56:17

如果您正在谈论任意文件,那么关于 UTC 的答案值得一试。时钟应该是相同的。

如果您可以控制文件和写入文件的机器,我会在文件的开头写一个版本号。然后就可以比较版本号了。如果两台机器独立写入文件,您将必须研究如何获取唯一的版本号。为了解决这个问题,可以实现两台机器都使用的版本 Web 服务。

某些文件格式具有内置版本信息和时间戳。例如,Microsoft Office 格式。然后,您可以使用内部信息来确定哪个是最新的。但最终也可能会出现版本冲突。

If you are talking about arbitrary files, then the answer about UTC is worth a try. The clocks should be the same.

If you have control over the files and the machines writing to them, I would write a version number at the start of the file. Then you can compare the version number. You would have to look into how to get unique version numbers if two machines write a file independently. To solve this, a version webservice could be implemented which both machines use.

Some file formats have version information built-in, and also time stamps. For example, Microsoft Office formats. You could then use the internal information to decide which was the newest. But you could end up with version conflict on these as well.

谜兔 2024-09-12 00:56:17

从您提出问题的方式来看,我认为由于某种原因您无法调用 DateTime 比较方法。假设如此,ticks 属性的 msdn 页面指出“单个刻度代表一百纳秒或百万分之一秒。一毫秒有 10,000 个刻度”。因此,刻度指的是 .NET 库分配的值,不依赖于机器/操作系统(可能是 Windows,因为您使用的是 C#),并且可以安全地用于比较。

From the way you phrased the question, I assume that for some reason you cannot call the DateTime comparison methods. Assuming this, the msdn page for the ticks property states "A single tick represents one hundred nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond." Thus the ticks refer to the value assigned by the .NET library and do not depend on the machine/OS(ehich is probably Windows since you are using C#) and can be safely used for comparisons.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文