On Tue, Jun 5, 2012 at 11:14 AM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote: > On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum <guido at python.org> wrote: >> What do they want to set the dst flag for? > > To shift the responsibility to deal with the DST ambiguity to the > user. This is what POSIX mktime with varying degree of success. > >> I think I am advocating for the former but without the dst flag. > > The cost of dst flag is low and most users will ignore it anyways, but > by providing it we will at least acknowledge the issue. I don't care > much one way or another. Me neither, TBH. Although if we ever get that "local time" tzinfo object, we may regret it. So I propose to launch without it and see if people object. There simply isn't a way to roundtrip for times that fall in the DST->std transition, and I doubt that many users will want to think about it (they'd have to store an extra bit with all their datetime objects -- it would be better to get them to use tzinfo objects instead...). > The remaining issue is the return type. Most of the use cases that > have been brought up cast the timestamp to int as soon as it is > computed. I recall a recent discussion about high-presision > timestamps, but don't recall the conclusion. I guess we should offer > timestamp() returning float and let those who care about range or > precision write their own solution. Python uses floats pretty much everywhere for posix timestamps. So let it return a float. -- --Guido van Rossum (python.org/~guido)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4