программистское: оставь надежду
Sep. 17th, 2003 07:39 pm1) Почитайте, как в Microsoft OLE устроена работа с датами, особенно датами до 1899-го года. Только заранее присядьте и отодвиньте от себя все легко бьющиеся предметы.
См. по этому поводу также у Айфыра.
2) Посмотрите на дерево XML-стандартов; если вам и после этого не станет плохо, у вас воистину железные нервы.
См. по этому поводу также у Айфыра.
2) Посмотрите на дерево XML-стандартов; если вам и после этого не станет плохо, у вас воистину железные нервы.
по поводу XML
Date: 2003-09-17 10:01 am (UTC)Я: So who came up with PKI?
S: Europeans
Я: Ah, damn europeans!
S: It's ok. We fought back. We invented XML.
Re: по поводу XML
Date: 2003-09-17 10:04 am (UTC)Если уж говорить об издевательствах над XML, но мне очень понравилась эта старая шутка о новом формате RSS.
no subject
Date: 2003-09-17 10:10 am (UTC)no subject
Date: 2003-09-17 10:56 am (UTC)Да, мне приходилось сталкиваться с этим печальным фактом.
2) Посмотрите на дерево XML-стандартов; если вам и после этого не станет плохо, у вас воистину железные нервы.
Я, в общем-то, представлял картину, и многие из этих стандартов знаю. Но таки да, стало немного плохо.
no subject
Date: 2003-09-17 11:04 am (UTC)И так всегда - добавляется примочка, которая не нужна, время жрет, да еще - неверно.
no subject
Date: 2003-09-17 12:56 pm (UTC)Видели, наверное, как в Солярисе (именно в нем - про свободные *nix'ы просто не в курсе, а в несвободных не видел) сделана установка переменнной TIMEZONE?
Длинный-длинный текстовый файл, где описано, как менялись часовые пояса в разных-разных странах мира за те времена, пока те люди, которым стоит thanks в комментариях, нашли и выяснили историю этих часовых поясов.
Проще говоря - сколько раз считывается календарь при работе финансовой программы? Сколько нужно времени, чтобы считать список перемены дат? Возможно, проблема в том, чтобы составить такой список, или я неправ?
PS. Для понимания. Я не программист. Я бывший IT-консультант в большой пятерке, а ныне начальник отдела, как это у на называется, "информационных систем", в серьезной нефтяной компании. Я понять хочу.
no subject
Date: 2003-09-17 02:39 pm (UTC)Не думаю, чтобы работа с этим занимала много времени. Во-первых, программы считывают не этот текстовый файл, а бинарный, полученный специальным компилятором zic(8). Я с этим не разбирался, но думаю, что при правильной организации этого файла особых проблем со скоростью быть не должно. Поиск -- вещь не хуже чем логарифмическая, в принципе.
no subject
Date: 2003-09-17 07:20 pm (UTC)Ну, тут есть такая проблема - если дату хранить в виде "день/месяц/год", то во-первых, надо указывать - по какому календарю, что делает ее еще крупнее, во вторых, во время любых вычислений "сколько дней между датой 1 и датой 2" - надо долго мучиться, с учетом обоих календарей. Можно хранить номер дня, считая от какого-то "начала", скажем - с 1 января 1970 года по Григорианскому календарю. Тогда, однако, надо переводить в "день/несяц/год" для печати, или, скажем, когда (частый случай в финансах) нужен конкретный день, к примеру - платить 15-го каждого месяца. Собственно, поскольку финансовые программы обычно за пределы 50 лет в прошлое не лазают, то можно принять, что календарь всегда - современный, Григорианский.
На самом деле с вычислением дат есть еще доплнительные прибамбасы, о которых Вы, конечно, знаете - скажем, конвенции. Их особенномного в бондах: 30/360, 30/360Е, Actual/365 и так далее - тут, даже, чтобы подсчитать количество дней между двумя датами надо переводить в "день/месяц/год". Кроме того, надо учитывать иногда - где обычный день, где выходной. Часто важно не в одной стране, а в нескольких. И хотелось бы это делать эффективно.
У астрономов - совсем другие заморочки. Они вообще день отсчитывают - с полудня, чтобы эксперимент одной ночи не попал в два разных дня :-)
А для операционной системы - совсем другие задачи. Ей надо как раз только следить, чтобы ее часы сответствовали тем, которые на стене висят. Опять же - зависит. Если компьютер ядерным реактором управляет - тут, может, имеет смысл накакать на "летнее время" для простоты и надежности.
Словом, вот. А Лакос - он попытался подбавить универсальности без смысла. Ну и никакой ценности не внес, программу замедлил, да еще и сделал неверно. Это, по-моему, самая большая проблема с нашим ремеслом - стремление к унивесальности. Все говорят о "компонентах", "code reuse", "seamless integration" - а понимает мало кто. Скажем, часто на интервью задают такой вопрос - должен ли класс "Пингвин" наследовать классу "Птица"? С одной стороны, вроде, пингвин - это птица. С другой, у птицы есть метод "летать", а у Пингвина что? Пустая заглушка? А беда тут простая - проблема оттого, что пингвин - это птица только с точки зрения биологической классификации. Не функциональной. А нам важно - в нашей программе, для нашей задачи, с точки зрения того, как мы его используем - птица он или нет? Может, мы пишем программу подготовки к полетам? А может - программу разделки и расфасофки мяса? Для них нужно разных пингвинов писать :-)
no subject
Date: 2003-09-18 04:04 am (UTC)Это и вызвало к жизни aspect-oriented programming %-)
А вопрос про наследование пингвина -- хороший; он должен отлично выявлять стиль мышления.
no subject
Date: 2003-09-17 11:15 am (UTC)no subject
Date: 2003-09-17 12:12 pm (UTC)no subject
Date: 2003-09-17 12:24 pm (UTC)Боже, какое убожество этот COM/ATL! Вспоминаю - вздрагиваю.
no subject
Date: 2003-09-17 12:25 pm (UTC)no subject
Date: 2003-09-17 03:16 pm (UTC)no subject
Date: 2003-09-18 01:54 am (UTC)cheeeesus, как же все запущено :)
на большее нет ни сил, ни слов :)
no subject
Date: 2003-09-18 05:34 am (UTC)no subject
Date: 2003-09-21 09:22 am (UTC)это про время, фундаментально: http://heim.ifi.uio.no/~enag/lugm-time.html
это про иксемель:
http://groups.google.com/groups?selm=%3C3250033069468718%40naggum.no%3E