On Tue, Jun 5, 2012 at 11:14 AM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum <gu...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
