Странное поведение POSIX для двух близких строк времени с указанием формата и без него

1. Почему часовой пояс отличается между двумя строками

Как сказано в комментариях, он отличается из-за перехода на летнее время. Поскольку вы не включаете зону в вызов as.POSIXct, вы подвержены многим проблемам. Когда это возможно, указывайте часовой пояс явно. Это нешуточный момент: если вы знаете его (и он не является частью строки), никогда не предполагайте, что он будет выведен правильно. По моему опыту, это будет достаточно неправильно, чтобы действительно раздражать и очень трудно обнаружить, найти и исправить.

2. Почему, когда формат не указан, он игнорирует часть времени

Это не так, хотя может показаться, что это так. Это всего лишь симптом того, как он распечатывается, а не сохраняется. (Это распространено во многих функциях R, например, как он показывает pi только с несколькими десятичными знаками, в то время как он, безусловно, хранит гораздо больше. Без этой модели «представление против фактической точности» консоль R была бы излишне заполнена десятичными знаками. и так постоянно)

Если я обновлю ваш код, чтобы явно включить зону:

as.POSIXct(c('2017-03-24 02:59:59', '2017-03-24 03:00:00'), tz="Israel")
# [1] "2017-03-24 IST" "2017-03-24 IST"
as.POSIXct(c('2017-03-24 02:59:59', '2017-03-24 03:00:00'), tz="Israel") + 1
# [1] "2017-03-24 00:00:01 IST" "2017-03-24 00:00:01 IST"

Во втором случае я добавил к времени одну секунду, и вы видите, что время теперь есть. Вы можете посмотреть на внутренности, чтобы увидеть это по-другому:

dput(as.POSIXct(c('2017-03-24 02:59:59', '2017-03-24 03:00:00'), tz="Israel"))
# structure(c(1490306400, 1490306400), class = c("POSIXct", "POSIXt"
# ), tzone = "Israel")
dput(as.POSIXct(c('2017-03-24 02:59:59', '2017-03-24 03:00:00'), tz="Israel")+1)
# structure(c(1490306401, 1490306401), tzone = "Israel", class = c("POSIXct", 
# "POSIXt"))

Время хранится в виде чисел с плавающей запятой и специального класса. Между ними (без прибавления 1 секунды и с добавлением 1 секунды) вы можете видеть, что числа просто отличаются друг от друга.

Третий способ подтверждения — взять posix-объекты «отсутствующего времени» и явно напечатать что-то (это уже не POSIXct, а просто для демонстрации):

a <- as.POSIXct(c('2017-03-24 02:59:59', '2017-03-24 03:00:00'), tz="Israel")
a
# [1] "2017-03-24 IST" "2017-03-24 IST"
format(a, format="the time is %Y-%m-%d %H:%M:%S")
# [1] "the time is 2017-03-24 00:00:00" "the time is 2017-03-24 00:00:00"

3. Почему не удается преобразовать первую строку, когда указан формат?

Как прокомментировал @Dave2e, согласно преобразованиям летнего времени, этого времени «никогда не было».

Согласно https://www.timeanddate.com/time/change/israel/jerusalem?year=2017:

24 марта 2017 г. – переход на летнее время

Когда местное стандартное время приближалось к пятнице, 24 марта 2017 г., 2:00:00, часы были переведены на 1 час вперед до пятницы, 24 марта 2017 г., 3:00:00 по местному летнему времени.

Я интерпретирую это так, что часы переместились с 01:59:59 на 03:00:00, поэтому 02:**:** никогда не было. R говорит вам с помощью NA, что этого времени не должно было произойти. Конечно, есть способы (взломы), с помощью которых можно вывести, что дело обстоит именно так: найти все значения NA, затем попытаться повторно преобразовать, используя плюс-минус час; если новое значение не NA, то вы нашли еще один случай, когда R считает, что время невозможно. Если это все еще NA, то в строке должно быть что-то еще (дополнительные символы, другой порядок и т. д.).

По моему опыту, я никогда не находил эту логику неправильной (хотя я не уверен, что она безупречна), даже если она кажется раздражающей. Когда я думал, что это может быть неправильно, я всегда находил что-то еще, что объясняло, почему я думаю, что у меня есть точное время:

• сбор данных сохранил неверную ТЗ
• при сборе данных не удалось сохранить TZ, и я сделал неправильный вывод
• некоторое преобразование в конвейере неправильно преобразовало время и / или зону (ы)
• скорее всего что-то еще я не искоренил