R as.POSIXct中可能存在的错误

我处理时间数据，并将其转换为POSIXct类（读取为字符串）。当我这样做时，它会处理我所有的数据，但不会处理一个特定的字符串。我所做的本质是：

Time1 <- '1900-04-01' # First Year then Month then Day
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d')

输出为：

[1] "1920-01-01 CMT"
[1] "1920-02-01 CMT"
[1] "1920-03-01 CMT"
[1] "1920-04-01 CMT"
[1] NA
[1] "1920-06-01 -04"
[1] "1920-07-01 -04"
[1] "1920-08-01 -04"
[1] "1920-09-01 -04"
[1] "1920-10-01 -04"
[1] "1920-11-01 -04"
[1] "1920-12-01 -04"

sessionInfo（）的输出：

---

您的本地设置似乎位于阿根廷。碰巧的是，阿根廷将该日期的时区从UTC-4:16:48重置为UTC-4。我想这意味着1920年5月5日阿根廷没有午夜。当您将该字符串转换为POSIXct时，它会在当天午夜在您所在的本地时区对其进行解释，这恰好是阿根廷不存在的时间。（这解释了为什么其他尝试相同代码的人无法复制该代码。）

在1894-10-31 00:00之前，阿根廷的各个地点观测当地平均时间 （在过渡后测量）。那一刻，整个国家 在科尔多瓦当地平均时间UTC-4:16:48进行同步。这个 下一次转换发生在1920-05-01 00:00，当时设置了时钟 领先16分48秒，成为UTC-4的平手。 阿根廷在UTC-4上保持统一，直到第一次夏令时 《时代》杂志创刊于1931年

如果需要POSIXct对象，可以考虑：

a） 指定当天午夜所在的不同时区

as.POSIXct("1920-05-01", tz = "UTC") 
# Or perhaps other nearby time zones didn't have that specific problem?

---

b） 在组件中存储时间，包括一个用于日期，一个用于一天内的时间。e、 g.

时间=小时（时间1）+分钟（时间1）/60

。这有点笨拙，但可能需要执行日期/时间计算。

对我来说也很好。可能是区域设置问题。请确保它实际上是

1920-05-01

，可能存在前导或尾随空格扫描。您共享

sessionInfo（）

的输出？我怀疑阿根廷当时进行了时间调整。从这里：#来自Paul Eggert（2002-01-22）：#“>#Hora de verano para la Republica Argentina（2000-10-01）#说阿根廷从1894-10-31#到1920-05-01的标准时间是-4:16:48.25。使用更精确的值#超过Shanks。是的，请看这里的更多：这是阿根廷改变时区的日期。

[1] "1920-01-01 CMT"
[1] "1920-02-01 CMT"
[1] "1920-03-01 CMT"
[1] "1920-04-01 CMT"
[1] NA
[1] "1920-06-01 -04"
[1] "1920-07-01 -04"
[1] "1920-08-01 -04"
[1] "1920-09-01 -04"
[1] "1920-10-01 -04"
[1] "1920-11-01 -04"
[1] "1920-12-01 -04"

R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

locale:
 [1] LC_CTYPE=es_AR.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=es_AR.UTF-8        LC_COLLATE=es_AR.UTF-8    
 [5] LC_MONETARY=es_AR.UTF-8    LC_MESSAGES=es_AR.UTF-8   
 [7] LC_PAPER=es_AR.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=es_AR.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods  
[7] base     

loaded via a namespace (and not attached):
[1] tools_3.3.3

as.POSIXct("1920-05-01", tz = "UTC") 
# Or perhaps other nearby time zones didn't have that specific problem?