我们正在以几个不同的时间间隔对Keen(通过Python)进行查询。
对于每个,我们将可选参数timezone
作为 named timezone 而不是绝对偏移量传递,以便它将考虑夏令时,例如:{{ 1}}
这适用于3个间隔。
每日适当考虑DST ...
"America/New_York"
... 每周 ......
{
timeframe: {
start: "2016-11-05T04:00:00.000Z",
end: "2016-11-06T04:00:00.000Z"
},
value: [ ... ],
},
{
timeframe: {
start: "2016-11-06T04:00:00.000Z",
end: "2016-11-07T05:00:00.000Z"
},
value: [ ... ],
},
{
timeframe: {
start: "2016-11-07T05:00:00.000Z",
end: "2016-11-08T05:00:00.000Z"
},
value: [ ... ],
}
......甚至每月。
{
timeframe: {
start: "2016-11-06T04:00:00.000Z",
end: "2016-11-13T05:00:00.000Z"
},
value: [ ... ],
},
...
{
timeframe: {
start: "2017-03-12T05:00:00.000Z",
end: "2017-03-19T04:00:00.000Z"
},
value: [ ... ],
}
每年但是不为DST调整...
{
timeframe: {
start: "2016-11-01T04:00:00.000Z",
end: "2016-12-01T05:00:00.000Z"
},
value: [ ... ],
},
...
{
timeframe: {
start: "2017-03-01T05:00:00.000Z",
end: "2017-04-01T04:00:00.000Z"
},
value: [ ... ],
}
...因为第二个时间帧(1月1日)的开始应该是{
timeframe: {
start: "2016-11-01T04:00:00.000Z",
end: "2017-01-01T04:00:00.000Z"
},
value: [ ... ],
},
...
{
timeframe: {
start: "2017-01-01T04:00:00.000Z",
end: "2017-11-01T04:00:00.000Z"
},
value: [ ... ],
}
偏移而不是T05:...
,就像之前的间隔一样。此外,由于第一个时间范围的结尾未经DST调整,因此显示为T04:...
而不是2017-01-01T04:...
。
除了2016-12-31T05:...
param之外,这些查询之间几乎没有任何变化。