Больше из любопытства, чем любая реальная проблема; вопрос появился сегодня, и я знаю, что видел 1899-12-30 как "дефолтную" дату и нулевую дату в приложениях Access и старых SQL Server. Просто задавался вопросом, почему - откуда это взялось и почему не используется 1899-12-31?
Почему 1899-12-30 нулевая дата в Access/SQL Server вместо 12/31?
Ответ 1
Поддержание совместимости с Lotus 1-2-3 в тот же день, у которого была ошибка в том, что он думал, что год 1900 года был високосным годом (или притворился?).
Объяснение слишком длинное, чтобы процитировать, но ради любопытства, вот некоторые фрагменты.
1900 не был високосным годом.
"Это ошибка в Excel!" Я воскликнул.
"Ну, не совсем, - сказал Эд." Мы должны были сделать это, потому что нам нужно иметь возможность импортировать рабочие листы Lotus 123 ".
" Итак, это ошибка в Lotus 123? "
" Да, но, возможно, преднамеренный. Лотос должен был вписаться в 640 тыс. Это не так много памяти. Если вы проигнорируете 1900 год, вы можете выяснить, является ли данный год високосным годом, просто посмотрев, правые два бита равны нулю.Это очень быстро и просто. Лотос-ребята, вероятно, полагали, что неважно было неправильно в течение этих двух месяцев в прошлом. Похоже, что базовые парни хотели быть анальными в течение этих двух месяцев, поэтому они вернули эпоху в один прекрасный день ".
Фактически, это число больше, чем фактическое количество дней. Это связано с тем, что Excel ведет себя так, как если бы существовала дата 1900-Feb-29. Это не так. 1900 год не был високосным (2000 год - високосный год). В Excel, на следующий день после 1900-Feb-28, 1900-Feb-29. В действительности, на следующий день после 1900-февраля-28 был 1900-марта-1. Это не "ошибка". Действительно, это по дизайну. Excel работает так, потому что это действительно ошибка в Lotus 123. Когда Excel был представлен, 123 имеет почти весь рынок программного обеспечения для работы с электронными таблицами. Microsoft решила продолжить ошибку Lotus, чтобы полностью совместимо. Пользователи, которые перешли от 123 в Excel, не должны были вносить какие-либо изменения в свои данные. Пока все ваши даты позже, чем в 1900-марте-1, это не должно беспокоить.
Ответ 2
Насколько я знаю, тип даты не существовал в "старшем SQL Server". Он был введен в SQL Server 2008 с нулевым значением даты, соответствующим 0001/01/01.
select cast(0x000000 as date),cast(CONVERT(date, '0001/01/01') as varbinary(max))
---------- --------
--0001-01-01 0x000000
Утверждения вопросов не имеют смысла. Если тип даты существовал в "более старом SQL Server", это означало бы несогласованную обратную совместимость типа даты в SQL Server 2008.
Нет смысла отвечать (и сообщения о повышении) в вопросе с помощью undefined или некорректно определенных терминов.
Ответ 3
SQL Server, похоже, возвращает эту дату по умолчанию, если он не может связаться с указанным источником времени.
Это произошло во время инцидентов при сбое кластера, когда моя биометрическая система посещаемости времени работает/используется.
Чтобы победить локальные манипуляции с часами, у кого-то часы, я спрашиваю экземпляр кластера SQL в какое время.
Он не может получить действительный активный источник времени и возвращает эту дату.
Обходной путь для меня прямолинейный, проверяя эту дату в моем GetServerTime Sub и используя время локального ПК, если возвращается этот "по умолчанию".
Я видел это с SQL 2000/2005/2008, все через ADO и VB6.