RDBMS метки времени для Hive временной метки временной зоны несоответствия

Question

Если я запрашиваю РСУБД, чтобы получить временную метку я получаю: 2015-03-30 00:00:00 После того как я экспортировать его в таблицу улей как BigInt колонке я получаю 1427673600000 (cast(ts as timestamp) gives 2015-03-30 02:00:00). I. Текущий часовой пояс (с летней экономией) применяется к отметке времени.

Если я хочу быть последовательным из того, что у нас есть в БД, как хранить экспортированные временные метки в Улье? Нужно ли всегда хранить временные метки в формате UTC в Hive, поэтому в этом случае мне нужно вычитать 2 часа с того, что я получил , а затем мне нужно применить текущий часовой пояс во время запроса (используя from_utc_timestamp)?
Как я могу учитывать летнее время (GMT + 1 и GMT + 2)?

Какая практика?

Answer 1

Улей хранит временные метки в миллисекундах с эпохи Unix. Hive docs on timestamps на самом деле ошибочны, потому что это Unix Epoch по определению в UTC.

Временная метка, которую вы дали (1427673600000), действительно соответствует 2015-03-30 00:00:00 UTC. Если это тот момент, который вы намереваетесь сохранить, то вы делаете это правильно. Если на самом деле вы намеревались просто сохранить дату календаря (ссылаясь на дату всего, а не на полуночью UTC в эту дату), тогда вам, вероятно, следует использовать тип DATE, сохраняя только 2015-03-30.

Вы спрашиваете, почему cast(ts as timestamp) дает 2015-03-30 02:00:00. Что, вероятно, происходит здесь, является то, что время экспортировано с исходной меткой времени, но когда вы получаете, он загружается в тип, который показывает вам местный эквивалент времени.

Например, это может произойти с java.util.Date. Вы должны уметь принимать это значение и интерпретировать его по-другому, либо с java.util.Calendar, либо с Joda-Time, либо с новыми классами Java 8 java.time. Если вы не используете Java, то аналогичный подход, вероятно, будет применяться. Дело в том, что вы, вероятно, используете Hive правильно, но локальный часовой пояс вводится при просмотре результатов.

ли мне нужно всегда сохранять метки времени в формате UTC в улье ...

Да, это лучшая практика, и это то, что вы делаете уже.

... так что в этом случае мне нужно вычесть 2 часа от того, что я получил ...

Нет, вы никогда не должны вручную добавить или вычесть время из метки времени. Это приведет вас к совершенно другому моменту времени.

... а затем я должен применить текущий часовой пояс во время запроса (используя from_utc_timestamp)?

Я не совсем знаком с Улей.Если посмотреть на the docs for from_utc_timestamp, то, похоже, это ожидает, что вход уже находится в метке времени, но они показывают пример с использованием строки. Возможно, это займет целое число, но тогда вы просто передали бы UTC в качестве часового пояса, практически ничего не делая при преобразовании значений. Вероятно, у вас все еще будет такая же проблема, особенно если проблема на стороне приема. ИМХО, я не думаю, что вам следует использовать это.