C# 将 UTC int 转换为 DateTime 对象
我不知道为什么这么复杂!
我有一个传递 long int UTC 的插件。我需要将该数字转换为 DateTime
来查询我的数据库 (SQL Server)。
我不知道为什么,但我无法从基本的谷歌搜索中找到可行的答案。
(为了额外加分,我需要在一天结束时将返回的 DateTime
转回 UTC。)
不得不问这样一个基本问题真是令人尴尬! :)
I don't know why this is so complicated!
I have a plugin that is passing in a long int UTC. I need to convert that number into a DateTime
to query my database (SQL Server).
I don't know why, but I can't find a workable answer from a basic google search.
(For extra credit, I need to turn my returned DateTime
back into a UTC at the end of the day.)
This is embarrassing to have to ask such a basic question! :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我的猜测是,这将是自特定纪元以来的毫秒或秒——很可能是 1970 年 1 月 1 日午夜 UTC 的 Unix 纪元。
因此,代码看起来像这样:
对秒进行明显的更改,或者从不同的纪元开始:)
另一种方法是创建自纪元以来的秒/毫秒的
TimeSpan
,然后添加它到纪元:我不知道它们之间有什么显着差异 - 尽管
AddMilliseconds
采用double
而不是long
的事实表明对于非常大的值,TimeSpan
方法可能更可取。我怀疑这会有什么不同:)My guess is it's going to be either milliseconds or seconds since a particular epoch - quite possibly the Unix epoch of January 1st 1970, midnight UTC.
So the code would look something like:
Make the obvious changes for seconds, or from a different epoch :)
An alternative approach is to create a
TimeSpan
of the seconds/milliseconds since the epoch, and then add it to the epoch:I don't know of any significant difference between them - although the fact that
AddMilliseconds
takes adouble
instead of along
suggests that for very large values, theTimeSpan
approach may be preferable. I doubt that it'll make any difference though :)你得到的 int 是秒、毫秒还是什么?将其转换为刻度后(一个 .NET 刻度为 100 纳秒),例如通过
longticks = theDBDateNum*TimeSpan.TicksPerMillisecond;
,尝试以下操作:Is the int you get seconds, milliseconds, or what? After converting it to ticks, (one .NET tick is 100 nanoseconds) e.g. by
long ticks = theDBDateNum*TimeSpan.TicksPerMillisecond;
, try this:根据 https://www.epochconverter.com/,
后来,
再后来,
According to https://www.epochconverter.com/,
And later,
Later still,