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 depends on #6835 and possibly on more. The issue here is that we need to parse a string to a timestamp in a different time zone. But we already don't really support parsing timestamps correctly as is. This is disabled by default. We require the year to be a full 4 digit year. We don't support all of the formats that cast does and we don't support parsing the time in a different timezone.
Hopefully we can just reuse the existing code and then convert the result to UTC using #6831 but we are going to have to do a lot of testing to see if that works. This might require that we write a custom kernel to do some of this. We might need to write a custom kernel at some point soon anyways to speed up timestamp parsing and to allow us to parse out time zones that could be included per string.
This is a fundamentally different problem than the other ones that pull out a part of a value from a timestamp. This is why it is a stand alone issue.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
This depends on #6835 and possibly on more. The issue here is that we need to parse a string to a timestamp in a different time zone. But we already don't really support parsing timestamps correctly as is. This is disabled by default. We require the year to be a full 4 digit year. We don't support all of the formats that cast does and we don't support parsing the time in a different timezone.
Hopefully we can just reuse the existing code and then convert the result to UTC using #6831 but we are going to have to do a lot of testing to see if that works. This might require that we write a custom kernel to do some of this. We might need to write a custom kernel at some point soon anyways to speed up timestamp parsing and to allow us to parse out time zones that could be included per string.
This is a fundamentally different problem than the other ones that pull out a part of a value from a timestamp. This is why it is a stand alone issue.
The text was updated successfully, but these errors were encountered: