如何将刻度转换为日期格式？

Posted 2023-04-12

【中文标题】如何将刻度转换为日期格式？

【英文标题】：How can I convert ticks to a date format?

【发布时间】：2010-12-02 03:12:27

【问题描述】：

我正在将刻度值转换为这样的日期：

Convert(datetime, (MachineGroups.TimeAdded - 599266080000000000)/864000000000);

使用这个我得到：

9/27/2009 10:50:27 PM

但我只想要这种格式的日期：

October 1, 2009

我的样本刻度值是

633896886277130000

最好的方法是什么？

【问题讨论】：

对我来说似乎是一个关于如何格式化 DateTime.ToString() 输出的非常真实的问题。

如果他阅读了我昨天对他的问题的回答，我已经提供了代码......

我对问题进行了大量编辑，以使其听起来更合法。原版需要改进。

他确实提供了代码方面的尝试，所以至少他表现出了努力。不知道昨天有人问过这个问题。尽管如此，我已经到了可能无法阅读“未知（谷歌）”的问题的地步。他们往往不会花太多时间来很好地提出问题。

【参考方案1】：

可以使用特定的刻度值构造 DateTime 对象。确定刻度值后，您可以执行以下操作：

DateTime myDate = new DateTime(numberOfTicks);
String test = myDate.ToString("MMMM dd, yyyy");

【参考方案2】：

这样做要简单得多：

DateTime dt = new DateTime(633896886277130000);

这给了

dt.ToString() ==> "9/27/2009 10:50:27 PM"

您可以使用dt.ToString(MyFormat) 任意设置格式。有关格式字符串，请参阅 this reference。 "MMMM dd, yyyy" 适用于您在问题中指定的内容。

不确定 10 月 1 日在哪里。

【讨论】：

october 1 只是一个格式示例。我需要转换语句，以便在 SQL 选择语句中使用它

【参考方案3】：

    private void button1_Click(object sender, EventArgs e)
    
        long myTicks = 633896886277130000;
        DateTime dtime = new DateTime(myTicks);
        MessageBox.Show(dtime.ToString("MMMM d, yyyy"));
    

给予

September 27, 2009

这是你需要的吗？

不过，我看不出这种格式在 SQL 查询中使用起来多么容易。

【参考方案4】：

到目前为止的答案帮助我想出了我的答案。我对UTC与当地时间保持警惕；刻度应始终为 UTC IMO。

public class Time

    public static void Timestamps()
    
        OutputTimestamp();
        Thread.Sleep(1000);
        OutputTimestamp();
    

    private static void OutputTimestamp()
    
        var timestamp = DateTime.UtcNow.Ticks;
        var localTicks = DateTime.Now.Ticks;
        var localTime = new DateTime(timestamp, DateTimeKind.Utc).ToLocalTime();
        Console.Out.WriteLine("Timestamp = 0.  Local ticks = 1.  Local time = 2.", timestamp, localTicks, localTime);
    

输出：

Timestamp = 636988286338754530.  Local ticks = 636988034338754530.  Local time = 2019-07-15 4:03:53 PM.
Timestamp = 636988286348878736.  Local ticks = 636988034348878736.  Local time = 2019-07-15 4:03:54 PM.

【讨论】：

赞成在存储日期/时间时关心 UTC。如果时区可能已更改，则在稍后检索时间时，更改时区可能会导致很多麻烦。