On Mon, Jun 4, 2012 at 5:51 PM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum <gu...@python.org> wrote: > .. >> But I don't know what ticks() is supposed to do. > > """ > .ticks(offset=0.0,dst=-1) > > Returns a float representing the instances value in ticks (see above). > > The conversion routine assumes that the stored date/time value is > given in local time. > > The given value for dst is used by the conversion (0 = DST off, 1 = > DST on, -1 = unkown) and offset is subtracted from the resulting > value. > > The method raises a RangeErrorexception if the objects value does not > fit into the system's ticks range. > > Note:On some platforms the C lib's mktime() function that this method > uses does not allow setting DST to an arbitrary value. The module > checks for this and raises a SystemError in case setting DST to 0 or 1 > does not result in valid results. > """ mxDateTime Documentation, > <http://www.egenix.com/products/python/mxBase/mxDateTime/doc/#_Toc293683804>
I agree that would be a step backward. >> I am assuming we >> would create totimestamp() and utctotimestamp() that mirror >> fromtimestamp() and utcfromtimestamp(). > > First, with the introduction of timezone.utc, the use of utc... > methods should be discouraged. Speak for yourself. TZ-less datetimes aren't going away and have plenty of use in contexts where the tz is either universally known or irrelevant. > fromtimestamp(s,timezeone.utc) is better than utcfromtimestamp(); > now(timezeone.utc) is better than utcnow(); and > dt.astimezone(timezone.utc).timetuple() is better than dt.utctimetuple() No, they are not better. They are simply different. > The advantage of the first two is that they produce aware datetime > instances. Whether that really is an advantage is up to the user and the API they are working with. > The last example may appear more verbose, but in most > applications, dt.astimezone(timezone.utc) is really what is needed. So you think. >> Since we trust the user with >> the latter we should trust them with the former. > This does not follow. When you deal with non-monotonic functions, > defining the inverse functions requires considerably more care than > defining the original. For example, defining sqrt(), requires > choosing the positive root. For arcsin(), you need to choose between > infinitely many branches. I don't think many users would appreciate > a math library where sqrt() and arcsin() take an optional branch= > argument, but mxDT's ticks() features this very design with its dst= > flag. Most users will ignore optional dst= and live with the > resulting bugs. We had several such bugs in stdlib and they went > unnoticed for years. That's why I don't recommend adding ticks(). But those math functions *do* exist and we need their equivalent in the stdlib. Users will have a *need* to convert their datetime objects (with or without tzinfo) to POSIX timestamps, and the one-liners from the docs are too hard to find and remember. While I agree that not every handy three lines of code need to become a function in the standard library, the reverse also doesn't follow: it just being three lines does not make it a sin to add it to the stdlib if those three lines are particularly hard to come up with. For datetimes with tzinfo, dt.totimestamp() should return (dt - epoch).total_seconds() where epoch is datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for timezones without tzinfo, a similar calculation should be performed assuming local time. The utctotimestamp() method should insist that dt has no tzinfo and then do a similar calculation again assuming the implied UTC timezone. I think these definitions are both sufficiently unsurprising and useful to add to the datetime module. -- --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
