Closed ganko-pi closed 10 months ago
@ganko-pi The only thing that the location
option affects is how windows are created across time-shift boundaries (daylight savings, British summer time, ect.). It does not change actual timestamps.
To change actual timestamps, you can timeShift()
to modify your timestamps by the offset of your timezone.
import "array"
import "date"
import "timezone"
time = 2023-11-14T12:00:00Z
array.from(rows: [{time: date.time(t: time)}])
|> yield(name: "UTC")
array.from(rows: [{time: date.time(t: time)}])
|> timeShift(columns: ["time"], duration: -8h)
|> yield(name: "America/Los_Angeles")
query | time |
---|---|
UTC | 2023-11-14T12:00:00Z |
America/Los_Angeles | 2023-11-14T04:00:00Z |
I, as you, feel that the location
option should be able to at least help modify timestamps. In this issue, I propose including a tzoffset
property in the location
record that represents the current offset of the specified timezone. You could then use that with timeShift()
to automatically update timestamps based on the current timezone offset.
I am not sure if you understand the issue. A timestamp conform to RFC3339 ending with a Z is an UTC time. So the update of the location should not modify the returned time because it is still UTC (indicated by the Z).
@ganko-pi You're right. I did misunderstand the issue. I didn't read carefully enough. Thanks for clarifying.
This issue has had no recent activity and will be closed soon.
Details
array.from(rows: [{version: runtime.version()}])
)Description
By running
date.time
with a set time zone the returned result is wrong.Example
Result
Expected behaviour
Both queries should return the set time 2023-11-14T12:00:00Z because it is an UTC time which is independent of a time zone.
Observed behaviour
The second query America/Los_Angeles returns
2023-11-14T04:00:00.000Z
and is off by eight ours (which is the offset of the set time zone America/Los_Angeles).