16

我目前正在编写一个相当简单的应用程序来处理企业的开/关时间，并且在试图弄清楚如何正确存储信息时遇到了严重的困难。

我们的大部分关键功能都严重依赖于让时间绝对完美，所以显然我希望以最好的方式完成工作！

此外，数据将由用户输入，因此如果底层表示稍微复杂一些（例如，使用 TimeSpan 来解释午夜过后的营业时间），这需要对用户不可见。

我需要首先存储业务的营业时间，按星期几，以及与之关联的时区，例如：

- M:  1000 - 2330
- T:  1000 - 0030
- W:  1900 - 0300
- Th: 2000 - 0300
- F:  2000 - 0800
- Sa: 1000 - 0500
- Su: 1000 - 2300

我目前认为存储它的最佳方法是使用这样的类：

public class OpeningHours
{
    ZonedDateTime OpeningTime { get; set; }
    Period durationOpen { get; set; }

    // TODO: add a method to calculate ClosingTime as a ZonedDateTime
}

然而，这里有两个主要的并发症：

  • 我不想存储 ZonedDateTime 的年、月或日期部分——我只关心 DayOfWeek。

    当然，我可以将每个值存储为 1970 年 1 月 1 日之后的第一个星期一/星期二等，但这似乎很老套，而且很明显是错误的——正如 NodaTime 的作者在谈到 BCL DateTime 的限制时非常正确地解释了这里执行。我也有一种感觉，如果稍后我们尝试对日期进行任何算术运算，最终可能会出现奇怪的古怪错误。

  • 无论如何，用户将不得不输入 ClosingTime。客户端我想我可以做一些简单的事情，比如总是假设ClosingTime是在OpeningTime之前的第二天，但同样，它并不完美，也没有考虑到可能开放超过24小时的地方（例如超级市场）

我考虑过的另一件事是使用带有小时/天的表格，并让人们突出显示一周中的几个小时来选择开放时间，但您仍然会遇到同样的问题，只想存储 OpenTime 的 DayOfWeek 部分。

任何建议都将不胜感激，在过去的 6 个小时里阅读我们人类代表时间的可笑愚蠢的方式让我有点筋疲力尽！

4

1 回答 1

19

出于以下几个原因，我强烈考虑使用LocalTime而不是：ZonedDateTime

  • 你不是试图代表一个单一的时刻；这些是自然重复的模式（没有关联的日期）
  • 您不是要应对商店在不同时区不同营业时间的情况；您可能希望将时区与每个商店关联一次，然后您可以随时应用该时区

所以我会有这样的东西（只显示数据成员；你如何整理行为是另一回事）：

public class StoreOpeningPeriod
{
    IsoDayOfWeek openingDayOfWeek;
    LocalTime openingTime;
    LocalTime closingTime;
}

请注意，这与您显示的原始数据完全一致，这始终是一个好兆头 - 您既不会添加也不会丢失信息，而且它可能是一种方便的形式。

如果收盘时间早于开盘时间，则假定它已经过了午夜——如果这种情况相对不常见，您可能希望为用户添加一个确认框，但在代码中肯定很容易发现和处理。

于 2013-03-31T22:57:51.607 回答