У меня есть данные в Google BigQuery, которые выглядят так:
sample_date_time_UTC time_zone milliseconds_between_samples
-------- --------- ----------------------------
2019-03-31 01:06:03 UTC Europe/Paris 60000
2019-03-31 01:16:03 UTC Europe/Paris 60000
...
Выборки данных ожидаются через равные промежутки времени, о чем свидетельствует значение поля milliseconds_between_samples
:
time_zone
- это строка, представляющая облако Google Поддерживаемое значение часового пояса
Затем я проверяю соотношение фактического количества выборок к ожидаемому числу зав любой конкретный день для любого отдельного дневного диапазона (выраженного в виде локальной даты для данного time_zone
):
with data as
(
select
-- convert sample_date_time_UTC to equivalent local datetime for the timezone
DATETIME(sample_date_time_UTC,time_zone) as localised_sample_date_time,
milliseconds_between_samples
from `mytable`
where sample_date_time between '2019-03-31 00:00:00.000000+01:00' and '2019-04-01 00:00:00.000000+02:00'
)
select date(localised_sample_date_time) as localised_date, count(*)/(86400000/avg(milliseconds_between_samples)) as ratio_of_daily_sample_count_to_expected
from data
group by localised_date
order by localised_date
Проблема заключается в том, что в этом есть ошибка, поскольку я жестко закодировал ожидаемое числомиллисекунд в день до 86400000
.Это неверно, так как, когда летнее время начинается с указанного time_zone
(Europe/Paris
), день становится на 1 час короче.Когда летнее время заканчивается, день увеличивается на 1 час.
Таким образом, приведенный выше запрос неверен.Он запрашивает данные за 31 марта этого года в часовом поясе Europe/Paris
(когда в этом часовом поясе началось летнее время).Миллисекунды в этот день должны быть 82800000
.
. В запросе как получить правильное количество миллисекунд для указанного localised_date
?
Обновление:
Я попытался сделать это, чтобы увидеть, что он возвращает:
select DATETIME_DIFF(DATETIME('2019-04-01 00:00:00.000000+02:00', 'Europe/Paris'), DATETIME('2019-03-31 00:00:00.000000+01:00', 'Europe/Paris'), MILLISECOND)
Это не сработало - я получаю 86400000