Давным-давно, один специалист по базам данных (из тех, бородатых и уже седых) сказал мне, что метки времени (timestamp) — это самая сложная тема в базах данных. Я ему, правда, не поверил, но приколы со временем реально встречаются.
Есть стандартная проблема, которую часто вижу в чужих данных. Положим собрались вы отслеживать события/действия пользователя. Обычно у вас будет это делать некий код (JS в вебе или SDK для аппов), который будет слать данные серверу.
Каждому событию нужна метка времени. И есть выбор из двух: локальное время на клиенте или время получения события сервером. Один хороший совет что делать и загадка без ответа под катом
По моему опыту от 1% до 5% пользователей (я смотрю по разным проектам и аудиториям) живут в далёком прошлом или даже в будущем. Я, честно сказать, не понимаю зачем они это делают.
Я заметил, что особенно много таких пользователей на Филиппинах и в Японии.
Эта проблема – реальный кошмар. Она ломает все запросы об активности пользователей в целом, а это самые популярные вопросы в аналитике.
Одно возможное решение – это создать собственный счётчик времени на клиенте. Спросить время у какого-нибудь сервера в интернете и запомнить разницу с системным временем. Но дело это муторное и гарантий, что сдвиг будет стабильным, особых нет (на этом девайсе уже гарантированно что-то не так со временем).
Так что же делать? Просто хранить обе метки времени и использовать более подходящую в зависимости от ситуации. Как всегда, больше данных — лучше. Но сделать это часто забывают. Затем и пишу, чтобы не забывали.
P.S. Вопросы залу:
Есть стандартная проблема, которую часто вижу в чужих данных. Положим собрались вы отслеживать события/действия пользователя. Обычно у вас будет это делать некий код (JS в вебе или SDK для аппов), который будет слать данные серверу.
Каждому событию нужна метка времени. И есть выбор из двух: локальное время на клиенте или время получения события сервером. Один хороший совет что делать и загадка без ответа под катом
Серверное время:
- Плюс: Полный контроль над точностью времени, форматом данных и часовым поясом. Всё стандартно, всё работает.
- Минус: На метку времени влияют лаги сети. Более того, если это приложение для смартфона, то наверняка вы используете загрузку данных партиями, чтобы минимизировать использование сети. Обычно события от пользователя хранятся локально пока не наберётся достаточно (например, 10) и затем они сливаются все за раз. Особую важность эта тактика, если работаете с развивающимися рынками, где больше половины устройств это максимально дешёвый Android подключенный через EDGE. В результате данные приходят партиями и у них одна временная метка на всех. Понять порядок и время между событиями не получается. Вот, кстати, другой похожий пример с хабра.
Клиентское время:
- Плюс: Даёт точные данные о порядке событий на клиенте и времени между ними
- Минус: Вы будете удивлены как часто у юзеров на девайсе установлено некорректное время!
По моему опыту от 1% до 5% пользователей (я смотрю по разным проектам и аудиториям) живут в далёком прошлом или даже в будущем. Я, честно сказать, не понимаю зачем они это делают.
Я заметил, что особенно много таких пользователей на Филиппинах и в Японии.
Эта проблема – реальный кошмар. Она ломает все запросы об активности пользователей в целом, а это самые популярные вопросы в аналитике.
Одно возможное решение – это создать собственный счётчик времени на клиенте. Спросить время у какого-нибудь сервера в интернете и запомнить разницу с системным временем. Но дело это муторное и гарантий, что сдвиг будет стабильным, особых нет (на этом девайсе уже гарантированно что-то не так со временем).
Так что же делать? Просто хранить обе метки времени и использовать более подходящую в зависимости от ситуации. Как всегда, больше данных — лучше. Но сделать это часто забывают. Затем и пишу, чтобы не забывали.
P.S. Вопросы залу:
- Другие способы?
- Есть идеи, что не так с японцами и филиппинцами?
