You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This is very similar to #6834 and does not depend on it, but does depend on #6831and #6832. But it probably would be good to have GpuHour working before we try to tackle this. The reason this one is on its own is because unix time stamps are in seconds where as a TimestampType is in microseconds. So the conversion to the desired time zone needs to be done in seconds. Ideally just like with GpuHour the existing CUDF code will work unchanged.
We also need to be very careful with our tests just like with GPU hour.
Note that with the new timezone support we need to be very careful that we test this for ambiguous times where we might need to do some normalization to get the same answer. These would include things like times during a daylight savings time transition where an overlap can occur and there is an hour when two different offsets could happen. We might need to not just do the conversion to microseconds, but we might also need to convert it to the desired time zone and then convert it back to UTC.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
This is very similar to #6834 and does not depend on it, but does depend on #6831and #6832. But it probably would be good to have
GpuHour
working before we try to tackle this. The reason this one is on its own is because unix time stamps are in seconds where as a TimestampType is in microseconds. So the conversion to the desired time zone needs to be done in seconds. Ideally just like withGpuHour
the existing CUDF code will work unchanged.We also need to be very careful with our tests just like with GPU hour.
Note that with the new timezone support we need to be very careful that we test this for ambiguous times where we might need to do some normalization to get the same answer. These would include things like times during a daylight savings time transition where an overlap can occur and there is an hour when two different offsets could happen. We might need to not just do the conversion to microseconds, but we might also need to convert it to the desired time zone and then convert it back to UTC.
The text was updated successfully, but these errors were encountered: