УФМС России по Камчатскому краю не согласилось с решением суда Петропавловска-Камчатского, обязавшего его выдать пенсионерке паспорт с указанием ее даты рождения — 29 февраля 1930 г., и подало апелляционную жалобу в Камчатский краевой суд.
Предыстория юридического противостояния чиновников заключается в том, что в соответствии с используемым сегодня календарем, 1930 г. високосным не являлся (то есть февраль этого года включал в себя только 28 дней). Именно по этой причине в информационной системе УФМС программное обеспечение указывает на невозможность оформления паспорта с несуществующей датой.
Другой вопрос, что дата рождения в выданном в итоге паспорте также является несуществующей — «00.00.1930». К тому же, как поясняет переселившаяся с Украины обладательница необычного документа, 1930 год не был високосным, но 29 февраля тогда все же было — в тот год СССР жил по советскому революционному календарю, просуществовавшему всего пару лет.
Вообще мне кажется, что работа ПО не может служить основанием для отказа от исполнения судебного решения. Если не может — значит оно должно быть доработано, чтобы смогло. По этому поводу в комментариях там хорошо сказано
Программист-идиот первого рода:
Нашёл некорректные данные, меняет их на своё усмотрение и ни о чём не предупреждает.
Программист-идиот второго рода:
Принял любые данные, корректность не проверяется.
Программист-дебил:
Нашёл некорректные данные, не применяет их, процесс ввода данных блокируется (в бытовухе — "не даёт ввести")
Нормальный программист:
Нашёл некорректные данные -> сообщил оператору -> принял данные от оператора с обоснованием.
Здравствуйте, Michael7, Вы писали:
M>Вообще мне кажется, что работа ПО не может служить основанием для отказа от исполнения судебного решения.
Так они же не отказываюся выполнять, а аппеляцию подали. Все в рамках закона. Другое дело, что такое сутяжничество государственной службы на бюджетные деньги одобрения не вызывает.
Здравствуйте, Michael7, Вы писали:
M>Проектировщикам информационных систем на заметку.
M>Вообще мне кажется, что работа ПО не может служить основанием для отказа от исполнения судебного решения. Если не может — значит оно должно быть доработано, чтобы смогло. По этому поводу в комментариях там хорошо сказано
M>
M>Программист-идиот первого рода:
M>Нашёл некорректные данные, меняет их на своё усмотрение и ни о чём не предупреждает.
M>Программист-идиот второго рода:
M>Принял любые данные, корректность не проверяется.
M>Программист-дебил:
M>Нашёл некорректные данные, не применяет их, процесс ввода данных блокируется (в бытовухе — "не даёт ввести")
M>Нормальный программист:
M>Нашёл некорректные данные -> сообщил оператору -> принял данные от оператора с обоснованием.
Нормальный программист, говоришь? А как оно вообще, по затратам времени/сил и вероятности возникновения? Провалидировать дату в григорианском календаре — довольно просто и быстро. А вот обработать все, даже минимально вероятные, исключения — тут как бы даже побольше работы. Тут мало даже разрешить вводить даты типа "29 февраля 1930 года", тут тебя могут попросить написать, к примеру, "31 квитня 1-го года Революции" или "13 цюфэня 4611 года". Как ты это всё будешь валидировать и в базу укладывать? Вообще валидацию нафиг отключить? А как использовать? Например, в случае с той вышепоименованной тётей — будет ей полных 86 лет на дату "29 февраля 2016 года", или нет? То есть, иногда это имеет значение. Или, допустим, человек родился 16 октября 1914 года — ему сейчас есть сто лет или нет? Чисто арифметически — да, а реально — еще почти две недели до ста лет. Затем, встаёт вопрос хранения данных в базе. Если разрешать использовать невалидные данные, то хранить дату рождения в поле DATE/TIMESTAMP, скорее всего, не получится — придется выкладывать кучей в стринг, либо создавать несколько полей — день, месяц, год. Затем писать логику поддержки операций над этим типом данных. И всё для ради маловероятного случая типа описанного в топик-стартере. Мне очень жаль этого "нормального программиста" — его ж начальники живьём съедят, без соли и кетчупа...
Так что лучше, имхо, конвертировать все эти невалидные даты в базовый формат. Если очень хочется сохранить исходные данные — можно выделить специальное место, например, поле комментария или специальных заметок.
M>Нормальный программист: M>Нашёл некорректные данные -> сообщил оператору -> принял данные от оператора с обоснованием.
То бишь, вводи куда хочешь, все что хочешь, но предоставь обоснование.
Начнут вводить даты по каким-нибудь китайским календарям, а программисту потом парсить обоснование и пытаться сконвертировать дату.
Здравствуйте, Michael7, Вы писали:
M>Вообще мне кажется, что работа ПО не может служить основанием для отказа от исполнения судебного решения.
Так это сейчас стало стандартной отмазкой и снятием ответственности с кого угодно — "ой, а у нас компьютер завис/программа не работает, мы не можем сделать то-то и то-то, приходите завтра".
Самое отмороженное было помню, когда жене вклад не выдали по окончанию срока — "у нас сегодня компьютер не работает", выдали только на следующий день.
M>Другой вопрос, что дата рождения в выданном в итоге паспорте также является несуществующей — «00.00.1930». К тому же, как поясняет переселившаяся с Украины обладательница необычного документа, 1930 год не был високосным, но 29 февраля тогда все же было — в тот год СССР жил по советскому революционному календарю, просуществовавшему всего пару лет.
Понимаешь... в нынешнем паспорте дата должна быть указана по нынешнему календарю.
То есть, ту дату нужно сконвертировать, а не пытаться вносить в документ календарь Майя или что-то подобное.
M>Программист-дебил: M>Нашёл некорректные данные, не применяет их, процесс ввода данных блокируется (в бытовухе — "не даёт ввести")
Ну я программист-дебил, именно так и делал и не стесняюсь в этом признаться. И считаю правильным. В ТЗ сказано "корректная дата григорианского календаря?" Так и реализовано.
Всякие исключения в стиле "писарь, шельмец, чернила экономил" (с) — это НЕТЕХНИЧЕСКАЯ проблема, это, фактически, некорректно оформленные документы у человека. Я живому человеку могу бесконечно сочувствовать, но путь решения юридической проблемы может быть только юридическим. Если же подобные исключения юридически допустимы, типа "как в паспорте/свидетельстве о рождении написано — так и вводим" — все это оговаривается на этапе постановки задачи. Любой каприз за ваши деньги, как говорится, но не надо фантазировать заранее и без четкого описания в ТЗ!
M>Нормальный программист: M>Нашёл некорректные данные -> сообщил оператору -> принял данные от оператора с обоснованием.
Каким еще обоснованием? Если список возможных исключений-обоснований известен заранее — он оговаривается в ТЗ. Не оговорен? Никаких исключений. Я бы лично еще сделал так, что ввести даже с оговоренным обоснованием подобные данные может только человек со специальными полномочиями, а не рядовой оператор. Рядовой оператор — дебил, которому все пофигу, исходить надо из такого предположения. Дай ему волю — база, при хоть сколько-то массовом вводе данных, моментально превратится в свалку. Плавали — знаем.
M>>Другой вопрос, что дата рождения в выданном в итоге паспорте также является несуществующей — «00.00.1930». К тому же, как поясняет переселившаяся с Украины обладательница необычного документа, 1930 год не был високосным, но 29 февраля тогда все же было — в тот год СССР жил по советскому революционному календарю, просуществовавшему всего пару лет.
A>Понимаешь... в нынешнем паспорте дата должна быть указана по нынешнему календарю.
1. 00.00.1930 — это какая-то уже совсем несуществующая дата
2. Почему? Вот, к примеру, место рождения указывают, как оно тогда называлось.
A>То есть, ту дату нужно сконвертировать, а не пытаться вносить в документ календарь Майя или что-то подобное.
Если конвертировать, тогда документ надо, удостоверяющий, что та дата, что в свидетельстве о рождении или старом паспорте и новая дата в новом паспорте — это одна и та же дата. Иначе придет человек куда-то, ну к примеру, с доверенностью, в ней написано: "гражданин такой-то, родился тогда-то, паспорта такой-то, проживает там-то", а в паспорте дата рождения другая. И будет доказывать, что это он. Старый-то номер паспорта в новом пропечатан.
Здравствуйте, namespace, Вы писали:
N>То бишь, вводи куда хочешь, все что хочешь, но предоставь обоснование. N>Начнут вводить даты по каким-нибудь китайским календарям, а программисту потом парсить обоснование и пытаться сконвертировать дату.
Ну так лучше всем родившимся до 1970 в дате рождения 0 ставить? А то ишь, придумали, рождаться до нулевой даты.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, TMU_1,
TMU> Я бы лично еще сделал так, что ввести даже с оговоренным обоснованием подобные данные может только человек со специальными полномочиями, а не рядовой оператор. Рядовой оператор — дебил, которому все пофигу, исходить надо из такого предположения.
Угу. Жизнь, знаешь ли, такая штука....
В реалиях жизни очень быстро эти "специальные полномочия" оказываются розданы абсолютно всем операторам. Причем раздают свои логины/ключи/пароли/отпечатки пальцев/etc. сами обладатели эти "специальных полномочий" — просто потому, что им лень лишний раз оторваться от стула. Плавали, знаем-с.
Конечно, проблема эта не техническая, а организационная, но человеческий фактор быстро сводит на нет все технологические ухищрения.
Здравствуйте, Michael7, Вы писали:
M>Проектировщикам информационных систем на заметку.
Тут надо ТЗ смотреть. Раньше первичен был документ, если там стоит 31 февраля, то будь любезен — прими эту дату. С руганью, угрозами, но прими и сохрани в базе. Сейчас ситуация могла измениться или архитекторы не подумали о таком варианте и сделали отлуп (поле date значительно удобнее ручного разбора на каждый чих). Как правильно решает не программист, а постановщик задач после изучения предметной области и долгих споров с заказчиком. Что интересно — техническую дату (00.00) они реализовали(означает лишь "месяц и день неизвестны", 00. — только день неизвестен), а 29е — нет. Можно было бы печатать XX или ХЗ в этом случае на месте цифр (дабы не пугать людей). Печатать пустое в документе нельзя — простота подделки.
TMU>> Я бы лично еще сделал так, что ввести даже с оговоренным обоснованием подобные данные может только человек со специальными полномочиями, а не рядовой оператор. Рядовой оператор — дебил, которому все пофигу, исходить надо из такого предположения. V_S>Угу. Жизнь, знаешь ли, такая штука.... V_S>В реалиях жизни очень быстро эти "специальные полномочия" оказываются розданы абсолютно всем операторам. Причем раздают свои логины/ключи/пароли/отпечатки пальцев/etc. сами обладатели эти "специальных полномочий" — просто потому, что им лень лишний раз оторваться от стула. Плавали, знаем-с.
Но наша (разработчиков) совесть чиста
V_S>Конечно, проблема эта не техническая, а организационная, но человеческий фактор быстро сводит на нет все технологические ухищрения.
Да понятно, что и уговаривать пользователей не наклеивать бумажки с паролями на монитор бесполезно, если только это не ФСБ/АНБ/военная какая-нибудь организация, где за нарушение установленных правил реально применяют санкции. Но это все же не повод пускать в сеть, скажем, или базу всех подряд без пароля
Здравствуйте, Jester, Вы писали:
J>Нормальный программист, говоришь? А как оно вообще, по затратам времени/сил и вероятности возникновения? Провалидировать дату в григорианском календаре — довольно просто и быстро. А вот обработать все, даже минимально вероятные, исключения — тут как бы даже побольше работы. Тут мало даже разрешить вводить даты типа "29 февраля 1930 года", тут тебя могут попросить написать, к примеру, "31 квитня 1-го года Революции" или "13 цюфэня 4611 года". Как ты это всё будешь валидировать и в базу укладывать?
К "нормальному" программисту постепенно приходит понимание, что когда обрабатываются миллионы данных "из жизни", то там встретиться может ВСЕ, даже мартобрь какой-нибудь и место рождения в галактике М31. Особенно, если обрабатываются документы из "докомпьютерной" эпохи. Кроме того, хотя в России сейчас принят григорианский календарь, на Земле есть страны и культуры и с иным календарем.
О чем это говорит? Что дату и время следует хранить в каком-то базовом виде, например, в количестве секунд с какой-то даты, а правила конвертации в и из символьного вида могут быть в теории разными для разных записей.
Это касается и не только дат. Я например, сталкивался в своей практике, что номера на госбумагах не уникальные, хотя они даже в теории должны быть уникальными. Причем дело не в фальшивости, а в бардаке с учетом. Например, если я буду когда-нибудь писать что-то учитывающее автомобильные номера, постараюсь предусмотреть, что они могут оказаться одинаковыми для разных людей или нарушать любые стандарты.
Здравствуйте, ToshiruWang, Вы писали:
TW>Здравствуйте, Michael7, Вы писали:
M>>Проектировщикам информационных систем на заметку.
TW>Тут надо ТЗ смотреть.
Я предполагаю, что такие заморочки в ТЗ вообще могли быть не оговорены. Про этот революционный календарь, почти уверен, что никто из разработчиков и заказчиков и не слышал, пока не наткнулись на такую хохму. Кстати, из коментариев там следует, что бабка далеко не единственная с такой проблемой.
TW> Раньше первичен был документ, если там стоит 31 февраля, то будь любезен — прими эту дату. С руганью, угрозами, но прими и сохрани в базе. Сейчас ситуация могла измениться или архитекторы не подумали о таком варианте и сделали отлуп (поле date значительно удобнее ручного разбора на каждый чих). Как правильно решает не программист, а постановщик задач после изучения предметной области и долгих споров с заказчиком. Что интересно — техническую дату (00.00) они реализовали(означает лишь "месяц и день неизвестны", 00. — только день неизвестен), а 29е — нет. Можно было бы печатать XX или ХЗ в этом случае на месте цифр (дабы не пугать людей). Печатать пустое в документе нельзя — простота подделки.
Думаю, что все еще проще: я не знаю СУБД в которой учитывался бы "революционный календарь". Это значит, что для работы с ним надо извращаться с промежуточными представлением — чего делать никто не захотел.
Вот подобных товарищей никогда нельзя допускать к разработке систем, комунницирующих с пользователем. Запомни еще раз и навсегда, интерфейс должен быть удобен для пользователя, а не программиста его пишущего.
Здравствуйте, Michael7, Вы писали:
M>Думаю, что все еще проще: я не знаю СУБД в которой учитывался бы "революционный календарь". Это значит, что для работы с ним надо извращаться с промежуточными представлением — чего делать никто не захотел.
Можно сделать отдельные таблицы (в терминах БД) для исключений, и соответствующие обработчики для них. Т.к. их немного, заметной деградации производительности не будет. Писать — да, больше придется.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, qaz321, Вы писали:
Q>Вот подобных товарищей никогда нельзя допускать к разработке систем, комунницирующих с пользователем. Запомни еще раз и навсегда, интерфейс должен быть удобен для пользователя, а не программиста его пишущего.
А при чем тут программист? Это проблемы составлявших ТЗ сапогов из МВД.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, qaz321, Вы писали:
Q>>Вот подобных товарищей никогда нельзя допускать к разработке систем, комунницирующих с пользователем. Запомни еще раз и навсегда, интерфейс должен быть удобен для пользователя, а не программиста его пишущего.
Ops>А при чем тут программист? Это проблемы составлявших ТЗ сапогов из МВД.
Понятно что проблемы в ТЗ, но обыно всю разрабатывающую команду непосвещенные в нашу провессию люди обобщенно называют "программисты", посему так написали в статье.
