You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by GitBox <gi...@apache.org> on 2020/08/19 15:15:03 UTC

[GitHub] [iceberg] RussellSpitzer commented on pull request #1355: Fixed non-greenway time zone, data loss with day partition

RussellSpitzer commented on pull request #1355:
URL: https://github.com/apache/iceberg/pull/1355#issuecomment-676488569


   The real issue here is not that the "Day" has to be in UTC, but that timestamps are in many cases transmitted without any timezone information, assuming that we can add that information back based on the System locale is going to essentially be buggy especially when we don't know where the System's running the code are actually located and this may be different for multiple users of the same table.
   
   One could imagine if you have a system running in both China and in US East you would get different answers with the same timestamps and this to me is the crux of the problem. System locale should not effect data partitioning.
   
   This is one of the (many) reasons that almost all modern apis for calculating Day or Day since Epoch don't represent the underlying time as a timestamp. There is just too much ambiguity in what the "day" should actually be. 


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org