1895 年 1 月 1 日的 String bug 中的 DateFormatter
我在 DateFormatter 的 .date(from: String) 函数中发现了最奇怪的错误,因为它似乎并不特别喜欢 1895-01-01 。上班前和下班后的日期,但该特定日期的日期为零。
我可以采用 1894-12-31 并添加一天来表明底层 NSDate 没问题——似乎只是 DateFormatter 转换。
这是要演示的游乐场代码。
import Foundation
let formatter = DateFormatter()
formatter.dateFormat = "yyyy-MM-dd"
let fmt = DateFormatter()
fmt.dateFormat = "yyyy-MM-dd"
let date1 = fmt.date(from: "1894-12-31")
let date2 = fmt.date(from: "1895-01-01")
let date3 = fmt.date(from: "1895-01-02")
let calcDate2 = date1?.addingTimeInterval(86400)
print("Date 1: \(date1)")
print("Date 2: \(date2)")
print("Date 3: \(date3)")
print("\nCalculated Date 2: \(calcDate2)")
输出是:
Date 1: Optional(1894-12-31 05:17:32 +0000)
Date 2: nil
Date 3: Optional(1895-01-02 05:00:00 +0000)
Calculated Date 2: Optional(1895-01-01 05:17:32 +0000)
我还发现了一个先前的问题 问题 关于奇怪的行为时间是在 1895 年左右添加的,所以也许这有某种关联?
这是一个错误吗?由于我不知道我的数据将包含哪些日期,所以在 JSON 解码时我知道如何解决这个问题吗?到目前为止,我只是在代码中将它用作字符串,但这不会持续很长时间。
I am finding the weirdest bug in DateFormatter's .date(from: String) function in that it doesn't seem to like 1895-01-01 specifically. Dates before and after work but for that particular day the date is nil.
I can take the 1894-12-31 and add a day to show that the underlying NSDate is fine -- just seems to be the DateFormatter conversion.
Here is the playground code to demonstrate.
import Foundation
let formatter = DateFormatter()
formatter.dateFormat = "yyyy-MM-dd"
let fmt = DateFormatter()
fmt.dateFormat = "yyyy-MM-dd"
let date1 = fmt.date(from: "1894-12-31")
let date2 = fmt.date(from: "1895-01-01")
let date3 = fmt.date(from: "1895-01-02")
let calcDate2 = date1?.addingTimeInterval(86400)
print("Date 1: \(date1)")
print("Date 2: \(date2)")
print("Date 3: \(date3)")
print("\nCalculated Date 2: \(calcDate2)")
Output is:
Date 1: Optional(1894-12-31 05:17:32 +0000)
Date 2: nil
Date 3: Optional(1895-01-02 05:00:00 +0000)
Calculated Date 2: Optional(1895-01-01 05:17:32 +0000)
I also found a prior issue issue about weird behaviour with time being added around 1895 so perhaps this is somehow related?
Is this a bug? Any idea how I can get around this when JSON decoding since I can't know what dates my data will contain? So far I'm just using it as a string in my code but that isn't going to work for long.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,答案是,由于铁路的使用需要更好的时间保持,因此许多州和省按照弗莱明几年前的建议于 1895 年采用了时区。
这就建立了太平洋时区、山区时区、中部时区和东部时区(我所在的地方)。因此,需要将东部时间调整为 00:17:32。因此新年时时钟从 23:59:59 变为 00:17:32。
这可以用以下代码显示:
输出是(对于 EST):
感谢所有帮助。
实际使用的解决方案是将“Z”时区添加到字符串格式的末尾,同样将“Z”附加到我调用的 API 的数据中。这迫使一切都到格林威治标准时间,而不会遇到这个问题。
感谢大家的帮助
Ok, the answer is that because the use of railroads required better time keeping a number of states and provinces adopted timezones in 1895 as suggested by Fleming several years earlier.
This established Pacific, Mountain, Central, and Eastern (where I am) timezones. As a result there was an adjust to Eastern of 00:17:32 required. So the clock went from 23:59:59 to 00:17:32 at New Years.
This can be shown with the following code:
Output is (for EST):
Thanks to all that helped.
The solution for actual usage is to add the "Z" time zone to the end of the string format and likewise append the "Z" to the data from the API I'm calling. That forces it all to GMT which doesn't suffer from the problem.
Thanks all for the assistance