Newb question time, what's BoF On Wed, Apr 8, 2015 at 7:31 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote:
> > On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher <ischwabac...@wisc.edu> > wrote: > > > > > So "storing the offset" and "storing a flag" are not two alternative > solutions to the same problem- these > > > are two solutions to two different problems. > > > > I'm viewing a time zone as a map from UTC to local time; for example, > America/Chicago is a time zone. I'm not proposing storing the offset as an > alternative to storing the *time zone*, I'm proposing it as an alternative > to storing whether a given time is DST or not. > > > When you are proposing to store something, you also need to specify where > you are proposing to store it. In the current design, local time > information is stored in the datetime object and the rules that govern UTC > to local mapping (and back) are stored in the tzinfo object. The > implementors of concrete tzinfo subclasses are supposed to have access to > time zone rules and implement utcoffset(dt), together with dst(dt) and > tzname(dt) methods. > > Storing isdst in the datetime object would allow utcoffset(dt) to > distinguish between 1:30AM before clock change and 1:30AM after. Where do > you propose to store the offset? If you store it in dt, why would you need > the tzinfo? > > > > > > We really don't care whether a time is DST or not; > > You may not care about it, but current tzinfo interface and > tzinfo.fromutc(dt) method do. Whatever new features are added to the > standard library, they cannot break existing uses. This means that > whatever concrete tzinfo implementations we add to stdlib, they must > provide an implementation of tzinfo.dst(dt) method. > > > So our times would look like "2013-11-03 01:30:00-0500 America/Chicago" > and an hour later, "2013-11-03 01:30:00-0600 America/Chicago". And all of > that information is stored in the datetime object. > > I don't think this is what most people would expect > > $ TZ=America/Chicago date > Wed Apr 8 18:26:01 CDT 2015 > > or > > $ TZ=America/Chicago date +"%c %z" > Wed 08 Apr 2015 06:27:09 PM CDT -0500 > > and not have location as a part of their timestamps. > > Regardless, whatever the proposal to add timezones to stdlib will end up > being, it must include the ability to implement an equivalent of UNIX date > command shown above. > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/alexmlord%40gmail.com > >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
