Психи

[metaclass]

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

Comments

[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 или точности выше секунды) — наилучший выбор.