Хьюстон...
Проблему 2000 я не заметил, так как персональная машина у меня появилась только летом 2000 года. На "компаньоне" это не было проблемой.
Много ли знает о проблеме 2038 года? Знаковое переполнение int-a. Таки, наверное, это не будет большой проблемой. Успеем везде перейти на int64. Только в музеях будет 32-битная архитектура. Ну, может еще на некоторых старых ядерных станциях.
А вот про проблему 2100 года в википедии пока не нашел. Проблема в том, что большая часть программистов не знает как определяется высокосность в Григорианском календаре. Точнее, не знает, что есть Юлианский календарь, что есть Григорианский календарь, и какой используется во всем мире. С большой вероятностью нас с Вами к этому времени не уже не будет, так что это уже не наша проблемы.
Хуже всего обнаруживать у себя в базе данных записи с часовым поясом (+5:45). Существуют извраты с (+4:51), но их выставить не так тривиально. А вот непальский часовой пояс - это было в реальности.
Так же очень сильно пугает, когда "какие-то гении" хранили дату в базе в тиках. Хотя нужен был лишь год. Из-за них умудрились на*ться с тем, что при передаче с клиента на сервер (с разными часовыми поясами) при десериализации время портилось (это блин, фишка платформы), и согласно констрейнтам на уникальность это все ложилось в две разные записи. А при подъеме в модель поднималась только одна, но в зависимости от положения звезд.
А еще больше пугает проблема президента. В википедии про нее тоже ничего нет. Но я думаю, все догадались. К счастью, это временная проблема. Или проблема 2012, или 2018, или 2024.
пятница, 25 марта 2011 г.
Подписаться на:
Комментарии к сообщению (Atom)
Комментариев нет:
Отправить комментарий