dzamo edited a comment on pull request #2268: URL: https://github.com/apache/drill/pull/2268#issuecomment-886007823
Thanks @paul-rogers. I think we're actually all nearly singing from the same hymn sheet now. Two last notes from me. #### Milliseconds since the "local epoch" (1970-01-01 00:00 local time zone). The following yield the same integer. 1. I tell Drill a zoneless time, Drill regards it as in UTC, Drill converts it to UNIX time (ms since the real, UTC-based epoch). 2. I tell Drill a zoneless time, Drill regards it as in the locally configured time zone, Drill extracts the "local UNIX time" (ms since the epoch in local time). I conclude that 1. The design, or spec, is (as you've explained) what is said by (2): Drill timestamps are milliseconds since the "local epoch", 2. @oleg-zinovev has nevertheless _not_ found bugs in the examples of (1) that he has presented here and we can keep his new code that does the same (for the TIMESTAMPs `left.value` and `right.value`, not for query start time - see my earlier test) #### Bug fix vs Improvement What we you think about me opening another ticket for us to do a second pass on these date functions? There is usage of Joda all over the place, tests coverage is spotty in places, there are lots of heap allocations, etc. Maybe doing this would mean Oleg's patch for a critical bug can remain simple and because we know we're coming back. Calendar arithmetic is so wicked that perhaps we'll always have libs and heap allocations here. -- 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]
