Yi Luan <itachi.l...@gmail.com> added the comment:
Hi Paul, Yes, I totally agree with you, and I should follow your advice and not to pass timestamps as representations of arbitrary datetime for interop usage. However in my particular case, I'm not the person who can make such type of decisions. Perhaps I'm very picky here but I think it would be more natural for `timestamp()` types of functions to return the arbitrary timestamp value(or vise versa) regardless of which timezone I'm in.....When interop and international operations were involved, Python's behavior might just add another level of conversion into the process and create more unnecessary confusion. I know I should always be aware of the timezone my machine is in and adding a tzinfo in the code for cross timezone operations in Python. But a simple code like: >>> datetime.datetime(2019, 1, 1, 0, 0, 0).timestamp() would generate different result on different machines across different timezone is, from my point of view, a confusing behavior, because, I can only be sure that I am the cautious one and putting tzinfo in, however, if there were multiple person in different timezone that didn't put tzinfo in and using different programming tools, the potential results of programs would be quite confusing (timestamp generated by python fed into other programming tools, or vise versa), but I understand that it is not a sound practice in the first place. Also, from my point of view, when not presented with tzinfo, the machine should not guess what timezone the programmer want this datetime.datetime(2019, 1, 1, 0, 0, 0) to be in, not to think that because my machine is in such such timezone so the timestamp() generated from datetime.datetime(2019, 1, 1, 0, 0, 0) would be 2019/1/1 00:00:00 minus or plus some hours. As you've mentioned: <quote> When you have a naive datetime (with no tzinfo), the only options are to pick the time zone it represents and convert to UTC or to throw an error and say, "We don't know what time zone this represents, so we cannot do this operation." Python 2 used to throw an exception, but in Python 3 naive datetimes represent local times. </quote> I think the appropriate option is to not pick any time zone at all, just viewing it as an "UTC"(return nominal value of timestamp()) other than "convert"-ing it to UTC(shifting by N hours based on the running machine's timezone), since we don't have any knowledge on which timezone this datetime object represents, we can't know if we have converted it truly to UTC or not, and to me, why bother shifting it by some hours and timestamp() it anyway, that's just another layer of calculation that could go wrong. Anyways, the above is just my personal opinion, obviously there is definitely nothing wrong with viewing an arbitrary datetime as a local time. Since you've mentioned that this behavior is intended, I'd assume and understand that this behavior is a result of balancing a lot of other choices. But from my point of view, as a clueless user, it might give me some confusion as to what the actual timestamp() I'm generating, or what the actual datetime I've imported when presented with an arbitrary timestamp. And generating timestamp on naive datetime objects regardless of what timezone the machine is in seems to be a more straight forward and clear thing to do. Again thanks very much for baring with me with this discussion. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39970> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
