我认为R错误地使用小数秒格式化POSIXct类型.我通过R-bugs提交了这个作为增强请求的内容,并且"我们认为当前的行为是正确的 - 删除了bug".虽然我非常感谢他们已经完成并将继续做的工作,但我想让其他人对这个特定问题采取行动,并且可能就如何更有效地提出要点提出建议.
这是一个例子:
> tt <- as.POSIXct('2011-10-11 07:49:36.3')
> strftime(tt,'%Y-%m-%d %H:%M:%OS1')
[1] "2011-10-11 07:49:36.2"
也就是说,tt创建为POSIXct时间,小数部分.3秒.当使用一个十进制数字打印时,显示的值为.2.我使用毫秒级精度的时间戳工作很多,这让我很烦恼,因为时间通常比实际值低一个等级.
以下是发生的事情:POSIXct是自纪元以来的浮点秒数.精确处理所有整数值,但在base-2浮点中,与.3最接近的值略小于.3.strftime()格式的所述行为%OSn是向下舍入到请求的小数位数,因此显示的结果为.2.对于其他小数部分,浮点值略高于输入的值,显示屏给出预期结果:
> tt <- as.POSIXct('2011-10-11 07:49:36.4')
> strftime(tt,'%Y-%m-%d %H:%M:%OS1')
[1] "2011-10-11 07:49:36.4"
开发人员的论点是,对于时间类型,我们应该总是向下舍入到请求的精度.例如,如果时间是11:59:59.8,那么用格式打印它%H:%M应该给出"11:59"而不是"12:00",并且%H:%M:%S 应该给出"11:59:59"而不是"12:00:00".我同意这个整数秒和格式标志%S,但我认为对于为小数部分秒设计的格式标志,行为应该是不同的.我希望看到%OSn使用舍入到最近的行为,即使是n = 0同时%S使用循环下来,从而使打印11:59:59.8与格式%H:%M:%OS0将给"12:00:00".这不会影响整数秒的任何事情,因为它们总是精确地表示,但它会更自然地处理小数秒的舍入误差.
这就是如何处理小数部分的打印,例如C,因为整数转换向下舍入:
double x = 9.97;
printf("%d\n",(int) x); // 9
printf("%.0f\n",x); // 10
printf("%.1f\n",x); // 10.0
printf("%.2f\n",x); // 9.97
我做了一个关于如何在其他语言和环境中处理小数秒的快速调查,并且似乎确实没有达成共识.大多数构造设计为整数秒,而小数部分是事后想法.在我看来,在这种情况下,R开发人员做出的选择并非完全不合理,但实际上并不是最好的选择,并且与其他地方用于显示浮点数的约定不一致.
人们的想法是什么？R行为是否正确？这是你自己设计它的方式吗？
我正在努力使用包含POSIXct的colClasses的read.csv将整个时间戳列向下舍入到最新的时间部分.我遇到了一个类似的问题,暗示我有一些约会可能会错过时间.情况并非如此.然而,在将我的矢量平分后,我注意到一些特定的时间戳应该受到指责.这是一个片段.
as.POSIXct(c("2016-03-13 01:00:00", "2016-03-13 02:00:00", "2016-03-13 03:00:00"))
这让我感到满意
[1] "2016-03-13 CST" "2016-03-13 CST" "2016-03-13 CST"
它是在DST过渡期,但不过时间部分在哪里？这是一个错误吗？
> version
_
platform i386-w64-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 3
minor 3.0
year 2016
month 05
day 03
svn rev 70573
language R
version.string R version 3.3.0 (2016-05-03)
nickname Supposedly Educational
更新
在全局设置时区时,似乎克服了这个问题,它对我来说仍然看起来像个错误.
更新2
我确认行为是特定于Windows的(特定于平台的错误？)这里是Ubuntu上R 3.2.3的输出
[1] "2016-03-13 01:00:00 CST" "2016-03-13 01:00:00 CST"
[3] "2016-03-13 03:00:00 CDT"
更新3
有一个已知的未经证实的错误#16852.
更新4
除非我遗漏了某些内容,否则我在%S和%OS之间的情况没有差异,如评论中所述.
> strptime(c("2016-03-13 …