在sqlite数据库中存储日历日
我需要在 sqlite 数据库中存储带有日历日期的项目(只是日期,没有时间)。 在列中表示日期的最佳方式是什么? 儒略日和 unix 秒是合理的替代方案。 如果我使用天以外的单位,那么应该是哪个时钟时间?
更新:我知道 ISO8601 并实际上使用它来将日期存储为原型的 YYYY-MM-DD 格式的字符串。 但对于各种算术,我必须在内部将其转换为某个数字,因此我更愿意存储一个数字并转换为字符串以进行显示。 这个数字应该采用什么单位,起源是什么,如果单位比天更精确,应该使用一天中的什么时间?
I need to store items with a calendar date (just the day, no time) in a sqlite database. What's the best way to represent the date in the column? Julian days and unix seconds come to mind as reasonable alternatives. If I go with a unit other than days at what clock time should it be?
Update: I am aware of ISO8601 and actually used it to store the date as a string in YYYY-MM-DD format for the prototype. But for various arithmetic I have to convert it to some number internally, so I'd prefer to store a number and just convert to string for display. What units should this number be in, with what origin, and if the units is more precise than days what time of day should be used?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
如果您想覆盖您的基础,请确保将日期存储在 utc 中并选择 ISO 标准。 这种方法只需最少的努力,并且可以保护您的代码免受未来互操作问题的困扰。
我同意@skymt ISO 8601 是一个不错的选择。
If you want to cover your bases make sure you store the date in utc and pick an iso standard. This approach requires minimal effort and will protect your code from future Interop headaches.
I agree with @skymt ISO 8601 is a good choice.
如果您使用 C++,那么 boost::date_time 非常值得一看。
If you are using C++, then boost::date_time is well worth a look.
“最佳”几乎完全取决于日期的来源(NSDate 对象、一些 XML feed)以及它们的操作方式(简单地按原样存储与进行一些算术运算,例如“天数”)。
我不一定推荐这样做,但我编写了一个应用程序,它也需要在 SQLite 数据库中存储日期而不是时间。 起初,我使用了“月”和“日”两列,其中“月”被定义为自 2000 年 1 月以来的月数。我需要强制每个日期一行,因此我在这两列之间定义了一个 UNIQUE 索引,结果变成了使更新速度非常慢。
在我的第二次尝试中,我使用了类似的方案,但将日期编码为一个数字,使用底部 5 位表示日期,其余较高位表示月份(同样,自 2000 年 1 月以来)。 转换函数是:
该方案保留了日期的数字顺序,并且可以轻松地将它们拆分为多个组件。 这对我的应用程序来说很有意义,因为我按月存储数据。 如果给定一个日期,您想要查找下一个日期,则此方案可能不是最好的,因为日期 + 1 可能不是有效日期。
"Best" almost entirely depends on where the dates come from (NSDate objects, some XML feed) and how they are manipulated (simply stored as-is vs. doing some arithmetic like "days until").
I'm not necessarily recommending this, but I wrote an app which also needed to store date-but-not-time in an SQLite DB. At first I used two columns, Month and Day, where Month was defined as the number of months since January 2000. I needed to enforce one-row-per-date, so I defined a UNIQUE index across those two columns, and it turned out to make updates horribly slow.
For my second attempt, I used a similar scheme but encoded the date into one number, by using the bottom 5 bits for the Day and the remaining upper bits for the Month (again, since Jan 2000). The conversion functions were:
This scheme preserves numerical order on dates and makes it easy to split them into components. It made sense for my app, because I was storing data in monthly chunks. If, given a Date, you want to find the next Date, this scheme might not be the best, since the Date + 1 may not be a valid date.
如果您希望将日期传递给外部工具或库,则应该使用它期望的任何格式。 Unix 时间似乎是数字钟表的通用语言,因此,如果外部环境无法为您做出选择,那么它是一个很好的默认值。
ISO 8601 可能会感兴趣。
编辑:
啊,这是有道理的。 如果您的环境(.NET?Python?C++?)有时间处理工具,最好使用它们的本机单位和纪元。 没有理由重写所有这些日期操作函数; 他们比看起来更棘手。 否则,我会使用本地(公历?)日历中自您的应用程序合理纪元以来的天数。 慷慨一点,当您突然需要处理比您预期早的日期时,您不希望出现反向千年虫错误。
一天中的时间完全取决于品味。 午夜似乎是最干净的选择(小时、分钟、秒字段中全部为零),但由于它永远不会到达用户,因此没有实际意义。 事实上,这将是一个复活节彩蛋的好地方。
If you expect to be handing the date to an external tool or library, you should use whatever format it expects. Unix time seems to be the lingua franca of digital horography, so it's a good default if external circumstances don't make the choice for you.
ISO 8601 may be of interest.
Edit:
Ah, that makes sense. If your environment (.NET? Python? C++?) has time-handling tools, it would be best to use their native unit and epoch. There's no reason to re-write all those date-manipulation functions; they're trickier than they look. Otherwise, I'd use days in the local (Gregorian?) calendar since a reasonable epoch for your application. Be generous, you don't want a reverse Y2K bug when you suddenly need to handle a date earlier than you ever expected.
The time of day is entirely a matter of taste. Midnight seems like the cleanest choice (all zeros in the hour, minute, second fields), but since it never reaches the user there's no practical implications. It would be a good spot for an easter egg, in fact.