Let's agree to disagree. I don't have the time to argue any more but you haven't convinced me.
On Mon, Jun 11, 2012 at 11:42 AM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum <gu...@python.org> wrote: > .. >> Maybe the problem here is the *input*? It should be a POSIX timestamp, >> not a datetime object. >> > > No. "Seconds since epoch" or "POSIX" timestamp is a foreign data type > to the datetime module. An aware datetime object with > tzinfo=timezone.utc or a naive datetime object representing UTC time > by convention is the datetime module way to represent absolute time. > If I need to convert time obtained from an e-mail header or a log file > to local time, I don't want to go through a "POSIX" timestamp. I > want the obvious code to work correctly: > >>>> t = datetime.strptime(time_string, format) >>>> local_time_string = datetime.localtime(t).strftime(format) > > (Note that the first statement already works in 3.2 if timezone > information is compatible with %z format.) > > .. >> Ok, I trust that LocalTimezone doesn't solve your problem. Separately, >> then, I still think we should have it in the stdlib, since it probably >> covers the most use cases besides the utc we already have. >> > > I am not against adding LocalTimezone to datetime. We can copy > tzinfo-examples.py to datetime.py and call it the day. However, this > will not eliminate the need for the localtime() function. > >> PS. TBH I don't care for the idea that we should try to hide the time >> module and consider it a low-level implementation detail for the shiny >> high-level datetime module. > > I don't think I ever promoted this idea. The time module has its > uses, but ATM it does not completely solve the local time problem > either. See <http://bugs.python.org/issue1647654>. > >> .. Users >> should be required to understand POSIX timestamps and the importance >> of UTC before they try to work with multiple timezones. > > I disagree. First, UTC and POSIX timestamps are not the same thing. > I am not talking about leap seconds or epoch. I just find this: > > $ TZ=UTC date > Mon Jun 11 18:15:48 UTC 2012 > > much easier to explain than this: > > $ TZ=UTC date +%s > 1339438586 > > There is no need to expose developers of e-mail servers or log > analytics to 9-10 digit integers or even longer floats. Second, UTC > is only special in the way that zero is special. If you write a > function converting incoming time string to local time, you don't need > to special case UTC as long as incoming format includes explicit > offset. > >> And they >> should store timestamps as POSIX timestamps, not as datetime objects >> with an (implicit or explicit) UTC timezone. > > I disagree again. At the end of the day, they should "store" > timestamps in a human-readable text format. For example, > > http://www.w3.org/TR/xmlschema-2/#isoformats > > Users who want an object that stores a POSIX timestamp internally, but > presents rich date-time interface can use an excellent mxDateTime > class. > > It is one thing to provide datetime.fromtimestamp() and > datetime.timestamp() methods for interoperability, it is quite another > thing to require users to convert their datetime instances to > timestamp for basic timezone operations. -- --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
