PatientZero21 окт в 15:33

«Большинство пользователей не работает с датами до 1 марта 1900 года, поэтому эта проблема встречается редко»

Простой

2 мин

9.3K

Office 365 * СофтWindows *

Перевод

+15

Комментарии 10

bbon 21 окт в 16:25

>Первая версия Lotus 1-2-3 предполагала, что 1900 год был високосным, хотя на самом деле он им не был.
Аккуратно напомню, что в Российской империи 1900 год был високосным, хотя какое дело этим таблицам до нашей печальной истории..

mikleh 21 окт в 23:26

Это не совсем так. По григорианскому календарю, который и используется в экселе, 1900 не был високосным, хоть в России, хоть в Сомали. Другое дело, что официальным календарем, действующим на территории России, на тот момент был юлианский, в котором 1900 високосный.

Gummilion 22 окт в 03:25

То есть, фактически Excel использует юлианский календарь, но с поправкой на текущие даты. А как в нем с 2100 годом, он тоже високосный? Как бы не пришлось в будущем еще проблему 2100 года решать…

Serge3leo 22 окт в 07:44

По-хорошему, надо смотреть документацию. Но по-быстрому, скажем, сейчас в MS Excel для macOS, 2100 год - нет, а даты за 1800 год не воспринимаются как даты.

Насчёт календарей, получается что где-то в XX/XXI веке он перешёл с юлианского на григорианский, почти как СССР, но без дырки в 13 дней. 😉

qyix7z 22 окт в 10:12

А как в нем с 2100 годом, он тоже високосный?

30 секунд на проверку, методом, как в статье

Sirion 22 окт в 10:56

Экселианский календарь

vanxant 22 окт в 14:49

вот только про невозможность фикса - врут как дышат. Особенно просто можно было перейти, когда вводили формат xlsx и про баг давно знали. Т.е. в xls даты хранились бы по прежнему, с багом, а в xlsx (который .xml.zip) - в виде ISO строки, как они собственно там и хранятся. Да, при сохранении в другой формат пришлось бы пересчитывать тудой-судой, но это не рокет саянс. Вместо этого дяде Билли оказалось легче продавить стандарт с описанием бага в комитете ISO и стандартизировать на всю планету как есть.