On Thu, Apr 16, 2015 at 1:00 AM, Lennart Regebro rege...@gmail.com wrote:
So because of this, perhaps we actually *should* change the internal
representation to UTC, because that makes the issues I'm fighting with
now so much simpler. (I'm currently trying to get arithmetic to do the
right
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico ros...@gmail.com wrote:
Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
more logical to describe it as adding six hours means adding six
hours to the UTC time, but it'd look extremely odd when there's a
leap second.
It
OK, so I just had a realization.
Because we want some internal flag to tell if the datetime is in DST
or not, the datetime pickle format will change. And the datetime
pickle format changing is the biggest reason I had against changing
the internal representation to UTC.
So because of this,
On Wed, Apr 15, 2015 at 11:43 AM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico ros...@gmail.com wrote:
Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
more logical to describe it as adding six hours means adding six
hours to
On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher
ischwabac...@wisc.edu wrote:
I am on the fence about EPOCH + offset as an internal representation. On the
one hand, it is conceptually cleaner than the horrible byte-packing that
exists today, but on the other hand, it has implications for
On 15-04-15, Lennart Regebro wrote:
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico ros...@gmail.com wrote:
Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
more logical to describe it as adding six hours means adding six
hours to the UTC time, but it'd look extremely
On 15-04-15, Lennart Regebro wrote:
On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher
ischwabac...@wisc.edu wrote:
I am on the fence about EPOCH + offset as an internal representation. On
the one hand, it is conceptually cleaner than the horrible byte-packing
that exists today, but on
Lennart Regebro rege...@gmail.com writes:
OK, so I realized another thing today, and that is that arithmetic
doesn't necessarily round trip.
For example, 2002-10-27 01:00 US/Eastern comes both in DST and STD.
But 2002-10-27 01:00 US/Eastern STD minus two days is 2002-10-25 01:00
US/Eastern
Isaac Schwabacher ischwabac...@wisc.edu writes:
...
I know that you can do datetime.now(tz), and you can do datetime(2013,
11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being able
to add a time zone to an existing naive datetime is painful (and
strptime doesn't even let you pass
On 15-04-15, Akira Li 4kir4...@gmail.com wrote:
Isaac Schwabacher ischwabac...@wisc.edu writes:
...
I know that you can do datetime.now(tz), and you can do datetime(2013,
11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being able
to add a time zone to an existing naive
Alexander Belopolsky alexander.belopol...@gmail.com writes:
Sorry for a truncated message. Please scroll past the quoted portion.
On Thu, Apr 9, 2015 at 10:21 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Apr 9, 2015 at 4:51 PM, Isaac Schwabacher
On 15 April 2015 at 17:00, Lennart Regebro rege...@gmail.com wrote:
OK, so I just had a realization.
Because we want some internal flag to tell if the datetime is in DST
or not, the datetime pickle format will change. And the datetime
pickle format changing is the biggest reason I had against
On Thu, Apr 16, 2015 at 1:43 AM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico ros...@gmail.com wrote:
Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
more logical to describe it as adding six hours means adding six
hours to the
Alexander Belopolsky alexander.belopol...@gmail.com writes:
On Wed, Apr 8, 2015 at 3:57 PM, Isaac Schwabacher ischwabac...@wisc.edu
wrote:
On 15-04-08, Alexander Belopolsky wrote:
With datetime, we also have a problem that POSIX APIs don't have to
deal with: local time
arithmetics. What
On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop stu...@stuartbishop.net wrote:
Huh. I didn't think you would need to change any arithmetic
Not really, the problem is in keeping the date normalized after each
call, and doing so the right way.
Arithmetic
remains 'add the timedelta to the naive
I don't see any obvious issues, but there may be some that don't need to be
marked stable.
Given that a mismatch here will cause build errors for users, I'm +1 on
checking this in.
Cheers,
Steve
Top-posted from my Windows Phone
From: Zachary
Isaac Schwabacher ischwabac...@wisc.edu writes:
On 15-04-15, Akira Li 4kir4...@gmail.com wrote:
Isaac Schwabacher ischwabac...@wisc.edu writes:
...
I know that you can do datetime.now(tz), and you can do datetime(2013,
11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being
Alexander Belopolsky alexander.belopol...@gmail.com writes:
...
For most world locations past discontinuities are fairly well documented
for at least a century and future changes are published with at least 6
months lead time.
It is important to note that the different versions of the tz
On 15-04-15, Akira Li 4kir4...@gmail.com wrote:
Isaac Schwabacher ischwabac...@wisc.edu writes:
On 15-04-15, Akira Li 4kir4...@gmail.com wrote:
Isaac Schwabacher ischwabac...@wisc.edu writes:
...
I know that you can do datetime.now(tz), and you can do datetime(2013,
11, 3, 1,
On Wed, Apr 15, 2015 at 4:46 PM, Akira Li 4kir4...@gmail.com wrote:
Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were
moved back one hour. So times like 01:30 AM happened twice there on that
day. Let's see how Python handles this situation
$ TZ=Europe/Kiev
On Wed, Apr 15, 2015 at 5:28 PM, Stuart Bishop stu...@stuartbishop.net
wrote:
On 15 April 2015 at 21:51, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop stu...@stuartbishop.net
wrote:
Just punting it to tzinfo to make adjustments, ie effectively just
On 15 April 2015 at 21:51, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop stu...@stuartbishop.net
wrote:
Just punting it to tzinfo to make adjustments, ie effectively just
doing what normalize() does creates infinite recursion as there is
more
Yeah, I just realized this. As long as you use timedelta, the
difference is of course not one day, but 24 hours. That solves the
problem, but it is surprising in other ways.
In US/Eastern datetime.datetime(2002, 10, 27, 1, 0) -
datetime.timedelta(1) needs to become datetime.datetime(2002, 10, 26,
23 matches
Mail list logo
