Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Nick Coghlanncoghlan at gmail.com
Wed Feb 15 12:43:17 CET 2012
On Wed, Feb 15, 2012 at 7:11 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:> I agree with Barry here (despite having voiced support for using Decimal> before): datetime.datetime *is* the right data type to represent time> stamps. If it means that it needs to be improved before it can be used> in practice, then so be it - improve it.By contrast, I think the only remotely viable choices for arbitraryprecision low level timestamp APIs are decimal.Decimal anddatetime.timedelta. The "unknown epoch" problem makes it impossible toconsistently produce datetime.datetime objects, and an API thatinconsistently returned either datetime.datetime or datetime.timedeltafor operations that currently consistently return float objects wouldjust be annoying.However, I still think that decimal.Decimal is the right choice.There's nothing wrong with layering APIs, and the core concept of atimestamp is simply a number representing a certain number of seconds.We already have a data type that lets us represent a numeric value toarbitrary precision: decimal.Decimal.Instead of trying to hoist all those APIs up to a higher semanticlevel, I'd prefer to just leave them as they are now: dealing withnumbers (originally ints, then floats to support microseconds, nowdecimal.Decimal to support nanoseconds and any future increases inprecision). If the higher level semantic API is incomplete, then weshould *complete it* instead of trying to mash the two differentlayers together indiscriminately.> I think improving datetime needs to go in two directions:> a) arbitrary-precision second fractions. My motivation for> proposing/supporting Decimal was that it can support arbitrary> precision, unlike any of the alternatives (except for using> numerator/denominator pairs). So just adding nanosecond resolution> to datetime is not enough: it needs to support arbitrary decimal> fractions (it doesn't need to support non-decimal fractions, IMO).If our core timestamp representation is decimal.Decimal, this istrivial to implement for both datetime and timedelta - just store theseconds component as a decimal.Decimal instance.If not, we'd have to come up with some other way of obtainingarbitrary precision numeric storage (which seems rather wasteful).Even if we end up going down the datetime.timedelta path for the osmodule APIs, that's still the way I would want to go - arranging fortimedelta.total_seconds() to return a Decimal value, rather than someother clumsy alternative like having a separate total_nanoseconds()function that returned a large integer.> b) distinction between universal time and local time. This distinction> is currently blurred; there should be prominent API to determine> whether a point-in-time is meant as universal time or local time.> In terminology of the datetime documentation, there needs to be> builtin support for "aware" (rather than "naive") UTC time, even> if that's the only timezone that comes with Python.As of 3.2, the datetime module already has full support for arbitraryfixed offsets from UTC, including datetime.timezone.utc (i.e. UTC+0),which allows timezone aware UTC. For 3.2+, you should only need athird party library like pytz if you want to support named timezones(including daylight savings changes).Cheers,Nick.-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Devmailing list
[8]ページ先頭