Психи

[metaclass]

http://people.onliner.by/2014/04/04/metro-29/
86400 - количество секунд в день. Разработчики умудрились как-то вычесть его из оставшегося на проездном количества поездок.
"Ошиблись полем".
Сразу видно олдскульных любителей Си и ассемблерных прошивок, мастеров байтоебства, которые никогда тестированием не заморачиваются, с первого раза все правильно делают.

Comments

[plumqqz.livejournal.com]

Да причем тут ассемблерные прошивки, я встречал совершенно несишных людей, которые дату в базе в юникстайме держали, потому что привыкли руки к топорам.

[kranov.livejournal.com]

юникс тай это фигня. Вот например процессинг smartvista фирмы БПЦ, мало того что дату и время хранит в двух разных полях типа number, и дата хранится 20140404 а время 193230, но 00:00:01 у них хранится в виде 1, а 01:01:00 это 10100.

и я вот переписывал (ускорял) запрос (dt >= SYSDATE - (5/(24*60))

было

      t.udate >= TO_NUMBER(to_char(SYSDATE - (10/(24*60)), 'YYYYMMDD')) and
      to_date(t.udate||':'||lpad(t.time,6,'0'),'YYYYMMDD:HH24MISS')> SYSDATE-(10/(24*60));
622  consistent gets

мой вариант

               (
                       (t.udate > TO_NUMBER(to_char(SYSDATE - (5/(24*60)), 'YYYYMMDD')))
                    or (
                          t.udate = TO_NUMBER(to_char(SYSDATE-(5/(24*60)), 'YYYYMMDD')) and
                          t.time  > TO_NUMBER(to_char(SYSDATE-(5/(24*60)), 'hh24miss'))
                       )
                 );
148  consistent gets

[orleanz.livejournal.com]

а что плохого в хранении даты в юникстайме? если например нужно часто считать дельты между разными значениями, разве это не самый оптимальный способ хранения?

а что касается конверсий в часовые пояса - поручаешь это чисто браузеру юзера и больше не паришься. Отдаешь браузеру юникс тайм, в дважаскрипт, и получаешь из бразуера юникс тайм, из дважаскипта.

[plumqqz.livejournal.com]

а что плохого в хранении даты в юникстайме? если например нужно часто считать дельты между разными значениями, разве это не самый оптимальный способ хранения?
Боюсь, я вас не понял.

а что касается конверсий в часовые пояса - поручаешь это чисто браузеру юзера и больше не паришься
В этой чудесной схеме возникает небольшая заминка в том случае, если нет ни браузера, ни джаваскрипта, ни даже юзера.

[prepor.livejournal.com]

Есть яп не умеющий переводить даты в юникстаймстемп? вы так и не сказали, чем же это плохо, хотя вот нашелся один явно интересующийся, а вот и второй подоспел.

[orleanz.livejournal.com]

ну так у вас написано - "а я видел, как (один раз) дату хранили в юникстайме". я к тому что ИНОГДА это совершенно не проблема. надеюсь вы знаете разницу между "иногда" и "всегда".

[astarsan.livejournal.com]

Если у вас клиенты в разных timezones (иначе бы вопрос не был актуален вообще).
То понятие платежи за сегодня для клиентов в разных timezones оно разное (с т.з. unixtime).
И разбивка платежей по календарным дням тоже разная (и вот это уже писать на unixtime c учетом timezones занятие ОЧЕНЬ так себе... скажу как человек который на это напарывался много раз).
И браузеру на откуп это не отдашь.
Проблема то не с отображением времени с учетом timezones а с КОРРЕКТНОЙ выборкой данных с учетом этих самых разных timezones и их свойств.

[andrew shadura (from livejournal.com)]

Как раз в случае клиентов в разных часовых поясах UNIX time (при условии отсутствия дат до 1970 или точности выше секунды) — наилучший выбор.

[osdm.livejournal.com]

Любая нормальная база данных умеет специальный тип для хранения даты-времени и умеет легко считать разницу между разными значениями этого типа и имеет кучу сервисных функций для работы с таким типом. Любой нормальный клиент к БД умеет переводить такой тип в тот формат, который принят в соответствующем клиентском языке программирования. Ни про какой юникстайм программеру, проектирующему БД, знать вообще не нужно.

[tzirechnoy.livejournal.com]

А чем тебе так не нравится база в юникстайме?
Не, ну понятно, что оно не соответствует никакому времени, но пересчёт в wall clock в общем нормальный.

[plumqqz.livejournal.com]

У меня брат 68 года.

[tzirechnoy.livejournal.com]

Стремаешься отрицательных чисел?

[plumqqz.livejournal.com]

Это какая-то совсем самодельщина непонятно во имя чего.

[orleanz.livejournal.com]

" непонятно во имя чего.

во имя простоты и надежности - что при проектировании сложных систем имеет адски важное значение.

юникстайм обеспечивает отсуствие всяческих двусмысленностей. а накладные издержки по конверсии из него и в него - пренебрежимо малы.

[plumqqz.livejournal.com]

С братом колхозим, с дедом (1896) делаем специально для него int64_t. Знаете, мне и без этого есть чем заняться.

[berezovsky.livejournal.com]

СПАСИБО ДЕДУ ЗА КВАРТИРУ

[plumqqz.livejournal.com]

Ура-а-а!!

[levgem.livejournal.com]

что плохого в держании даты в юникстайме?

[plumqqz.livejournal.com]

Смотрите выше.

[levgem.livejournal.com]

вы к тому, что при отсутствии типизации на уровне БД могут появляться такие проблемы из-за недотестированности кода?

[plumqqz.livejournal.com]

Я к тому, что иметь особый ни с чем толком не совместимый тип для дат с 1970 года с точностью в секунду, и другой тип для дат не только с 1970 года и с разной точностью очевидный идиотизм.