avantgardnerio commented on issue #4106:
URL: 
https://github.com/apache/arrow-datafusion/issues/4106#issuecomment-1304563978

   > no ambiguity in this approach
   
   I disagree. The problem is that `America/Denver` is on a statuary (legally 
constructed) timezone called [Mountain Time](https://time.is/MT). Because 
Mountain Time (presently) observes Daylight Savings Time, it is two "real" 
timezones: [MDT](https://time.is/MDT) or UTC-6 and [MST](https://time.is/MST) 
UTC-7.
   
   
![image](https://user-images.githubusercontent.com/3855243/200126237-740b3d3d-9b37-4748-816f-89d8e371ffb5.png)
   
   Unfortunately, this Sunday (2022-11-06), MT will be switching from UTC-6 to 
UTC-7 at 02:00 MDT, which will cause the clocks to go to 01:00 MST, and about 
half an hour later it will be 1:30AM MT for the second time this year.
   
   So while I agree there is no ambiguity for `to_timestamp('05 Dec 2000', 'DD 
Mon YYYY')`, I think we need a test case specifically for `select 
TO_TIMESTAMP('2022-11-06T01:30:00');`, because given only that the only 
information known is:
   
   1. `2022-11-06T01:30:00`
   2. and `America/Denver`
   
   There is no way to infer if this means there is no way to know if that 
corresponds with `1667745000` (UTC-6) or `1667748600` (UTC-7).
   
   
![image](https://user-images.githubusercontent.com/3855243/200126506-ce557d10-4b63-43f4-a9a1-ba7eb8656e74.png)
   
   https://www.unixtimestamp.com/index.php
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to