Вот сейчас переименовалась киевская таймзона. Сколько с этим проблем. От пользователей она уже приходит, а сервера о ней знать не знают. Надо всё обновлять. Либо городить костыли с подменой таймзоны и огрести из-за этого проблем чуть позже, когда tzdata таки обновится.
Если пользователь планирует событие, то он, конечно, планирует его в своей таймзоне, и она тут же конвертируется в UTC, сервер делает выборки тоже в UTC и ничего не знает о том, какая зона была у пользователя в момент создания задачи. Тут нет противоречия. Есть просто другой класс задач, где прямая арифметика с секундами является приемлемой, потому что никакой конкретной таймзоны для них нет.
Захотелось купить это, чтобы попробовать на вкус. Это я совершенно серьёзно. А вообще, если действительно удалось достичь всех заявленных характеристик, то это большое достижение, очень хорошее даже.
У меня, кстати, есть ваш электропроводный Уни спрей, использую его, чтобы смочить контактные плошадки пульсометра, так вот он пахнет отвратительно. Мне кажется, он с ароматизатором пота.
Так может вы обоснуете почему нельзя? Конкретная описанная мной задача не связана с пользовательскими таймзонами. Чиста бэкендная задача очистки. Какую таймзону нужно выбрать тогда?
Такой тип с тремя числами хорош для операций (например для прибавления месяца поменять нужно максимум два числа, и правило смены там элементарное)
Не обязательно два и необязательно элементарное. Если к 31.01 прибавить 1 месяц, то это какое число будет? Точно не 31.02. А как тогда правильно, округлиться до последнего числа февраля или валить в март? В любом из этих случаев надо ещё и знать високосный ли год.
Есть у нас и такие задачи. Пользователь говорит, что некое действие должно быть совершено в такое-то время в его таймзоне. При сохранении задачи время конвертируется в UTC и сохраняется. Дальше сервер делает выборки в зоне UTC, чтобы понять какие задачи надо выполнить. И хотя сервер работает в другой таймзоне, время выполнения будет то, что указал пользователь.
Нет, это не так работает. Допустим пользователь в Москве загружает файл в 15:00. В UTC это будет 12:00. Файл удалится через 86400 секунд, по UTC это будет 12:00 следующих суток. Для пользователя в его московской таймзоне это будет 15:00 следующих суток, плюс минус час, на случай перехода DST (которого в неудачно выбранной мной московской зоне нет).
В итоге для одних данные останутся за 6.5 дней, а для других за 7.5 дней
Так не будет. Пользователь загружал данные в своей таймзоне и наблюдает их изменение в ней же. Погрешность возможна только в районе часа при смене DST, а это не важно в данном случае.
Полчетвёртого ещё ладно. В детстве меня подвешивали определения времени вроде "четверть пятого" или "двадцать минут шестого". С половинами я как-то справлялся на лету (не знаю почему, они по сути не отличаются), а вот такие определения приходилось реально раскручивать в голове. Ага, идёт шестой час, значит полных часов пять и ещё двадцать минут. На мой взгляд, часы со стрелками не объясняют зачем переключаться между количественными и порядковыми числительными. Со стрелочных часов вполне легко считывается "пять двадцать". Ещё можно понять зачем говорить "без пяти пять" или "без четверти пять" - стрелка часовая ближе к пяти (и при этом нет перехода к порядковым числительным), но "двадцать минут шестого" зачем?
Ну это понятно. Я сам занят в сервисе, который работает по всему миру и пользователи используют неограниченный набор таймзон. Как раз тут и нужно прибить время к фиксированной таймзоне при хранении. Пользователь передаёт данные в своей таймзоне, если это интервал, то оба его конца конвертируются в timestamp независимо с использованием tzdata, и там будут учтены переводы времени.
При этом расчёты для внутренних целей можно делать простой арифметикой. Например, мне надо удалить неиспользуемые данные старше 7 дней. Я могу при этом использовать простую арифметику и вычесть 7*86400 из текущего количества секунд. Собственно иначе в какой таймзоне я должен считать?
Как говорил эксперт по выбору из двух вариантов (по совместительству солист группы Бредор): обе альтернативы не лишены недостатков, поэтому категоричный выбор не приносит удовлетворения.
Недавно я писал код по транспонированию матрицы, в нём удобнее работать с массивом нумерованным от нуля. Так при расчёте индексов при перестановках исключается постоянное добавление и вычитание единицы, код становится значительно менее перегруженным и более понятным.
С другой стороны, когда код работает с порядковыми числительными из реального мира, зачастую гораздо нагляднее выглядит нумерация с единицы. Банальный пример - словарь месяцев, которые и в человеческом календаре нумеруются с единицы, как и в большинстве языков программирования (кроме, кажется, JS). Тут же, не отходя от календаря стоит вспомнить, что дни недели зачастую нумеруются с нуля, либо и так и так.
Если язык программирования предоставляет выбор, это удобно.
Рассуждения по поводу нумерации индексов в C выглядят как попытка рационализировать постфактум то, что и так легко объясняется арифметикой указателей.
Вот сейчас переименовалась киевская таймзона. Сколько с этим проблем. От пользователей она уже приходит, а сервера о ней знать не знают. Надо всё обновлять. Либо городить костыли с подменой таймзоны и огрести из-за этого проблем чуть позже, когда tzdata таки обновится.
Если пользователь планирует событие, то он, конечно, планирует его в своей таймзоне, и она тут же конвертируется в UTC, сервер делает выборки тоже в UTC и ничего не знает о том, какая зона была у пользователя в момент создания задачи. Тут нет противоречия. Есть просто другой класс задач, где прямая арифметика с секундами является приемлемой, потому что никакой конкретной таймзоны для них нет.
Гельтек, казалось бы, на Хабре выглядит странно, но я с удовольствием читаю их статьи. Они, может, не про IT, но про разработку. И хорошо написаны.
Раз уж добавлена Звёздочка, то рядом в аптечке можно поискать Финалгон.
Захотелось купить это, чтобы попробовать на вкус. Это я совершенно серьёзно. А вообще, если действительно удалось достичь всех заявленных характеристик, то это большое достижение, очень хорошее даже.
У меня, кстати, есть ваш электропроводный Уни спрей, использую его, чтобы смочить контактные плошадки пульсометра, так вот он пахнет отвратительно. Мне кажется, он с ароматизатором пота.
Так может вы обоснуете почему нельзя? Конкретная описанная мной задача не связана с пользовательскими таймзонами. Чиста бэкендная задача очистки. Какую таймзону нужно выбрать тогда?
Не обязательно два и необязательно элементарное. Если к 31.01 прибавить 1 месяц, то это какое число будет? Точно не 31.02. А как тогда правильно, округлиться до последнего числа февраля или валить в март? В любом из этих случаев надо ещё и знать високосный ли год.
Есть у нас и такие задачи. Пользователь говорит, что некое действие должно быть совершено в такое-то время в его таймзоне. При сохранении задачи время конвертируется в UTC и сохраняется. Дальше сервер делает выборки в зоне UTC, чтобы понять какие задачи надо выполнить. И хотя сервер работает в другой таймзоне, время выполнения будет то, что указал пользователь.
Нет, это не так работает. Допустим пользователь в Москве загружает файл в 15:00. В UTC это будет 12:00. Файл удалится через 86400 секунд, по UTC это будет 12:00 следующих суток. Для пользователя в его московской таймзоне это будет 15:00 следующих суток, плюс минус час, на случай перехода DST (которого в неудачно выбранной мной московской зоне нет).
Так не будет. Пользователь загружал данные в своей таймзоне и наблюдает их изменение в ней же. Погрешность возможна только в районе часа при смене DST, а это не важно в данном случае.
А если говорят "без четверти пять", а встреча в 18:00 (так в письме написано), не надо делать пересчёты в голове?
Полчетвёртого ещё ладно. В детстве меня подвешивали определения времени вроде "четверть пятого" или "двадцать минут шестого". С половинами я как-то справлялся на лету (не знаю почему, они по сути не отличаются), а вот такие определения приходилось реально раскручивать в голове. Ага, идёт шестой час, значит полных часов пять и ещё двадцать минут. На мой взгляд, часы со стрелками не объясняют зачем переключаться между количественными и порядковыми числительными. Со стрелочных часов вполне легко считывается "пять двадцать". Ещё можно понять зачем говорить "без пяти пять" или "без четверти пять" - стрелка часовая ближе к пяти (и при этом нет перехода к порядковым числительным), но "двадцать минут шестого" зачем?
Ну это понятно. Я сам занят в сервисе, который работает по всему миру и пользователи используют неограниченный набор таймзон. Как раз тут и нужно прибить время к фиксированной таймзоне при хранении. Пользователь передаёт данные в своей таймзоне, если это интервал, то оба его конца конвертируются в timestamp независимо с использованием tzdata, и там будут учтены переводы времени.
При этом расчёты для внутренних целей можно делать простой арифметикой. Например, мне надо удалить неиспользуемые данные старше 7 дней. Я могу при этом использовать простую арифметику и вычесть 7*86400 из текущего количества секунд. Собственно иначе в какой таймзоне я должен считать?
Как говорил эксперт по выбору из двух вариантов (по совместительству солист группы Бредор): обе альтернативы не лишены недостатков, поэтому категоричный выбор не приносит удовлетворения.
Недавно я писал код по транспонированию матрицы, в нём удобнее работать с массивом нумерованным от нуля. Так при расчёте индексов при перестановках исключается постоянное добавление и вычитание единицы, код становится значительно менее перегруженным и более понятным.
С другой стороны, когда код работает с порядковыми числительными из реального мира, зачастую гораздо нагляднее выглядит нумерация с единицы. Банальный пример - словарь месяцев, которые и в человеческом календаре нумеруются с единицы, как и в большинстве языков программирования (кроме, кажется, JS). Тут же, не отходя от календаря стоит вспомнить, что дни недели зачастую нумеруются с нуля, либо и так и так.
Если язык программирования предоставляет выбор, это удобно.
Рассуждения по поводу нумерации индексов в C выглядят как попытка рационализировать постфактум то, что и так легко объясняется арифметикой указателей.
Но если в UTC работаешь, то это ж не проблема.
Это количественные и порядковые числительные. Прожитых лет 0, год жизни первый.
И котиков. Котиков мыть травмоопасно, а иногда приходится.
Не, без автоклавирования какая стерильность?
Всё верно.
Из-за секунды коррекции получается неправильное число секунд между двумя датами, а это может быть важно не только астрономам.