一整天24 小时周期的收盘/开盘的 Noda 时间表示

问题描述

我正在解析来自 https://raw.githubusercontent.com/QuantConnect/Lean/master/Data/market-hours/market-hours-database.json

的一些有趣的格式化数据

它包含一个片段（删除了几天），如下所示：

"Future-cme-[*]": {
      "dataTimeZone": "UTC","exchangeTimeZone": "America/Chicago","monday": [
        {
          "start": "00:00:00","end": "1.00:00:00","state": "market"
        }
      ],"friday": [
        {
          "start": "00:00:00","end": "16:00:00","state": "market"
        }
      ]
}

我正在使用 JsonConverter<LocalTime> 来转换上述内容，并且可以毫无问题地将 friday 属性 start 和 end 解析为 LocalTime。

然而，这代表一整天的日期，即 1.00:00:00 它抛出一个错误，因为它不是 ISO 格式 - 这引发了关于我（不正确！）使用结构的问题。

目前我的格式使用 LocalTime 如下：

public class MarketHouRSSegment
{
    public LocalTime Start { get; init; }
    public LocalTime End { get; init; }
    public MarketHouRSState State { get; init; }
}

和格式化程序：

public class LocalTimeConverter : JsonConverter<LocalTime>
{
    public override LocalTime Read(ref Utf8JsonReader reader,Type typetoConvert,JsonSerializerOptions options)
    {
         return LocalTimePattern
                    .GeneralIso
                    .Parse(reader.GetString())
                    .GetValueOrThrow();
    }

    public override void Write(Utf8JsonWriter writer,LocalTime value,JsonSerializerOptions options)
    {
        writer.WriteStringValue(value.ToString());
    }
}

是否有首选方法来处理代表 24 小时跨度的 LocalTime？

我会在 1:00:00:00 中检测到 reader.GetString() 转换器，如果是，设置为 00:00:00（午夜）并检查是否 Start == End 那么我们知道这是一个完整的 24 小时周期吗？
或者将 Start 作为 LocalTime 是否更正确，以及带有 End => Start + Duration?
的小时（即 24 小时）的持续时间

解决方法

是否有首选方法来处理代表 24 小时跨度的 LocalTime？

值得后退一步，非常仔细和精确地分离不同的概念。 LocalTime 不代表 24 小时跨度 - 它只是一天中的一个时间。两个 LocalTime 值可以有效地表示 24 小时跨度，而无需参考特定日期，是的。

如果您可以将 JSON 更改为使用 00:00:00，然后将“开始==结束”情况视为一整天，那么我会这样做。然而，这确实意味着你永远不能代表一个空时期。

现在，就您是否应该使用开始和持续时间而言……这实际上取决于您要建模的内容。您是要模拟开始时间和结束时间，还是开始时间和持续时间？到目前为止，您已经将一整天称为“24 小时跨度”，但情况并非总是如此，如果您要处理具有 UTC 偏移转换的时区（例如，由于夏令时）。

转换已经导致像这样的本地时间间隔的潜在问题 - 如果您在本地时间从凌晨 2 点“回退”到凌晨 1 点的日期工作，并且您有本地时间段（例如）00： 30 到 01:30，那么逻辑上这将在一天中的一个半小时内“正确”：

00:00-00:30：错误
00:30-01:30（第一次）：正确
01:30-02:00（第一次）：错误
01:00-01:30（第二次）：正确
01:30-02:00（第二次）：错误
02:00-00:00（第二天）：错误

我们真的不知道您对这些期间做了什么，但这是您需要考虑的事情……同样，如果您将某事表示为“24 小时的 00:00”，那是如何工作的一天只有 23 小时，还是有 25 小时？这将非常很大程度上取决于您对数据的处理方式。

我会采用以下流程：

制定详细的要求，包括您希望在特定时区出现 UTC 偏移转换的日子里发生的事情（并在此阶段考虑测试）
根据 Noda 时间类型从这些要求中提取逻辑值（有限制，不，很遗憾，我们不支持 24:00:00 作为 LocalTime）
尽可能在 JSON 中表示这些类型
让您的代码在处理数据的方式方面尽可能地遵循您的需求文档

nodatime quantconnect