WEKA 使用 SimpleDateFormat 解析我的日期......除非它涉及 2 o'钟
我有一个大的 ARFF 文件，其中的数据看起来像这样：
555,"2011-03-13 01:50:48.000",0
540,"2011-03-13 02:10:19.000",0
为了帮助解析它，我声明了第二个属性，如下所示：
@attribute RecordedOn date "yyyy-MM-dd HH:mm:ss.SSS"
解析器使用 Java 的 SimpleDateFormat，对于第一行（以及非常重要的几百万行）工作得很好。与它类似），但有几行被噎住了，就像第二行一样。我注意到它只会阻塞小时为“02”的一行——事实上，如果我将其更改为 540,"2011-03-13 01:10:19.000"，第二行就可以很好地解析， 0 。更神秘的是，一些带有 02 的行无论如何都可以很好地解析。例如： 1,"2006-12-16 02:58:51.000",111
那么有人知道发生了什么吗？有什么建议吗？提前致谢。
I have a large ARFF file with data that looks something like this:
555,"2011-03-13 01:50:48.000",0
540,"2011-03-13 02:10:19.000",0
To help parse it, I declared the second attribute like this:
@attribute RecordedOn date "yyyy-MM-dd HH:mm:ss.SSS"
The parser, which uses Java's SimpleDateFormat, works fine for the first line (and the couple million lines that are very similar to it), but chokes on a few lines, like the second one. I've noticed that it only chokes one lines whose hour is "02"--in fact, the second line is parsed fine if I change it to 540,"2011-03-13 01:10:19.000",0. To add to the mystery, some lines with a 02 are parsed fine anyway. Like: 1,"2006-12-16 02:58:51.000",111
So does anyone know what's happening? Any advice? Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您几乎可以肯定将日期解释为遵守夏令时的时区的当地时间。 2011年3月13日是美国夏令时的开始；这意味着时钟从 01:59:59 前进到 03:00:00，跳过整个 2 点钟时间。 “2011-03-13 02:10:19.000”当地时间从未出现在例如纽约市。
You are almost certainly interpreting the dates as local times in a time zone that observes Daylight Saving Time. March 13, 2011 was the start of Daylight Saving Time in the United States; this means the clock advances from 01:59:59 to 03:00:00, skipping the entire 2 o'clock hour. "2011-03-13 02:10:19.000" local time never occurred in, e.g., New York City.
我对某些数据也有同样的问题，我可以通过将系统时区更改为美国/菲尼克斯来使用它（因为他们不使用 DST）。我后来发现的其他解决方案是在运行 WEKA 时更改 JVM 的时区（ https: //www.baeldung.com/java-jvm-time-zone )
I had the same problem with some data and I could use it by changing my system timezone to America/Phoenix (since they do not use DST). Other solution I found later is to just change the timezone of the JVM when running WEKA ( https://www.baeldung.com/java-jvm-time-zone )