Cassandra select query with timezone issue

Question

У нас есть два разных кластера cassandra на двух разных часовых поясах.

• CLUSTER1: 2.1.8 версии, с IST TZ
• Cluster2: 2.1.9 версии, с UTC TZ

На CLUSTER1 для запроса на выборку с колонкой отметки времени, я не нужно упомянуть tz [+0530], тогда как на другом кластере я должен и должен предоставить значение TZ в select query для извлечения строки. Это связано с версией cassandra?

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

cluster1:

select * from test.check where row_timestamp = '1970-01-01 00:00:00'; 

cluster2:

select * from test.check where row_timestamp = '1970-01-01 00:00:00+0000'; 

ЕСЛИ нет TZ не упоминается, я получаю "0" строк. Я не хочу давать TZ в cluster2, пожалуйста, примите, как это сделать.

Answer 1

Это немного странно, я должен признать, но могут быть некоторые изменения в манипуляции часовым поясом между 2.1.8 и 2.1.9. Это из журнала изменений:

(cqlsh) Исправление отметок времени до 1970 года на Windows, всегда использовать UTC для временной меткой дисплея (Cassandra-10000)

С другой стороны, документация совершенно ясно по данному вопросу:

Если не указано часового пояса, используется часовой пояс координатора узла Кассандра , передачи запроса на запись. Для точности, DataStax рекомендует указывать часовой пояс, а не полагаться на часовой пояс, настроенный на узлах Cassandra.

Итак, моя искренняя рекомендация - указать часовой пояс и указать то же самое, предположительно GMT (или время UTC). Спасите себе головную боль. Mind, GMT is not exactly equal to UTC, there is a slight difference in meaning. Таким образом, вы должны игнорировать настройки часовых поясов на кластерах. Временная метка в конечном счете сохраняется как несколько миллисекунд (с определенной точки). Информация о часовом поясе - это просто «визуализация». Количество пропущенных миллисекунд одинаково, например, 2015/03/05 14:00:00+0100 и 2015/03/05 16:00:00+0300.

Если вы ничего не указываете и получаете 0 результатов, в то время как вы получаете результаты при использовании +0000, убедитесь, что данные, которые вы ожидаете первоначально, записываются с ожидаемым часовым поясом. Возможно, из-за этого на самом деле нет никаких данных в промежутке, или временная метка координационного узла отличается.