Terry Reedy wrote:
"A rich comparison method may return the singleton NotImplemented if it
does not implement the operation for a given pair of arguments. By
convention, False and True are returned for a successful comparison.
However, these methods can return any value,"
That's to give the
On Tue, Jun 5, 2012 at 5:48 PM, Terry Reedy wrote:
> 3.3 enhancement or backported bugfix?
Please move this discussion to the tracker: http://bugs.python.org/issue15006
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
On 6/5/2012 3:17 PM, Guido van Rossum wrote:
On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
wrote:
On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote:
You could say the same about equally "confusing" results, yet equality never
raises TypeError (except between datetime instances):
Just to correct a misapprehension seen in this thread: there are still
plenty of closed systems on the planet where every machine is set to UTC so
that "local" time is UTC regardless of where the machine is physically
located. You just won't hear about many of those systems if you're not
working on
Good point.
On Tue, Jun 5, 2012 at 12:17 PM, Guido van Rossum wrote:
> On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
> wrote:
>> On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote:
>>> You could say the same about equally "confusing" results, yet equality never
>>> raises TypeError (e
On Tue, Jun 5, 2012 at 12:15 PM, Alexander Belopolsky
wrote:
> On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote:
>> You could say the same about equally "confusing" results, yet equality never
>> raises TypeError (except between datetime instances):
>>
> () == []
>> False
>
> And even clo
On Tue, Jun 5, 2012 at 3:01 PM, Antoine Pitrou wrote:
> You could say the same about equally "confusing" results, yet equality never
> raises TypeError (except between datetime instances):
>
() == []
> False
And even closer to home,
>>> date(2012,6,1) == datetime(2012,6,1)
False
I agree, e
Le 05/06/2012 20:37, Alexandre Zani a écrit :
This is nice when your datetime objects are freshly created. It is not so
nice when some of them already exist e.g. in a database (using an ORM
layer). Mixing naive and aware datetimes is currently a catastrophe, since
even basic operations such as e
On Tue, Jun 5, 2012 at 11:26 AM, Antoine Pitrou wrote:
> Le 05/06/2012 19:21, Alexander Belopolsky a écrit :
>
>> with timezone.utc added to datetime module
>> already the cost of supplying tzinfo to UTC datetime objects is low.
>
>
> This is nice when your datetime objects are freshly created. It
Le 05/06/2012 19:21, Alexander Belopolsky a écrit :
with timezone.utc added to datetime module
already the cost of supplying tzinfo to UTC datetime objects is low.
This is nice when your datetime objects are freshly created. It is not
so nice when some of them already exist e.g. in a database
On Tue, Jun 5, 2012 at 11:21 AM, Alexander Belopolsky
wrote:
> On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote:
>> Maybe you need to get out more. :-) This is how datetime is
>> represented in App Engine's datastore:
>> https://developers.google.com/appengine/docs/python/datastore/typesand
On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote:
> Maybe you need to get out more. :-) This is how datetime is
> represented in App Engine's datastore:
> https://developers.google.com/appengine/docs/python/datastore/typesandpropertyclasses#DateTimeProperty
> (Note: These docs are unclear ab
On Tue, Jun 5, 2012 at 11:14 AM, Alexander Belopolsky
wrote:
> On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote:
>> What do they want to set the dst flag for?
>
> To shift the responsibility to deal with the DST ambiguity to the
> user. This is what POSIX mktime with varying degree of suc
On Tue, Jun 5, 2012 at 1:41 PM, Guido van Rossum wrote:
> What do they want to set the dst flag for?
To shift the responsibility to deal with the DST ambiguity to the
user. This is what POSIX mktime with varying degree of success.
> I think I am advocating for the former but without the dst fl
On Tue, Jun 5, 2012 at 10:21 AM, Alexander Belopolsky
wrote:
> On Tue, Jun 5, 2012 at 9:45 AM, Guido van Rossum wrote:
>> TZ-less datetimes aren't going away and have
>> plenty of use in contexts where the tz is either universally known or
>> irrelevant.
>
> I agree, but in these contexts naive d
On Tue, Jun 5, 2012 at 9:45 AM, Guido van Rossum wrote:
> TZ-less datetimes aren't going away and have
> plenty of use in contexts where the tz is either universally known or
> irrelevant.
I agree, but in these contexts naive datetime objects almost always
represent local time in some "universall
On Tue, Jun 5, 2012 at 5:07 PM, Guido van Rossum wrote:
> In fact, we might go further and define fromtimestamp() to do the same
> thing. Then the only difference between the two would be what timezone
> they use if there is *no* tzinfo. That's fine with me.
Yeah, that sounds good.
Cheers,
Dirk
On Tue, Jun 5, 2012 at 7:19 AM, Dirkjan Ochtman wrote:
> On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum wrote:
>> For datetimes with tzinfo, dt.totimestamp() should return (dt -
>> epoch).total_seconds() where epoch is
>> datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for
>> timezon
On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum wrote:
> 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
>
On Mon, Jun 4, 2012 at 5:51 PM, Alexander Belopolsky
wrote:
> On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum 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 con
On 04.06.12 13:19, Dirkjan Ochtman wrote:
I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when converting dateti
On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum 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 tim
On Mon, Jun 4, 2012 at 1:57 PM, Alexander Belopolsky
wrote:
> On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum wrote:
>> You seem to have misread -- I don't want to check if they are exactly
>> 24 hours apart. I want to check if they are at most 24 hours apart.
>> The timezone can be assumed to b
On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum wrote:
> You seem to have misread -- I don't want to check if they are exactly
> 24 hours apart. I want to check if they are at most 24 hours apart.
> The timezone can be assumed to be the same on dt1 and dt2.
>
> A variant of (1) was what was neede
> Anyway, I was pointed to issue 2736, which seems to have got a lot of
> discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
> name just a few) up against Alexander (the datetime maintainer,
> AFAIK). It seems like a fairly straightforward case of practicality
> over purity: Alex
On Mon, Jun 4, 2012 at 11:46 AM, Alexander Belopolsky
wrote:
> On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum wrote:
>> ... I heard
>> a colleague complain that he'd lost several hours trying to figure out
>> how to determine whether two datetimes were within 24h of each other,
>> getting conf
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum wrote:
> ... I heard
> a colleague complain that he'd lost several hours trying to figure out
> how to determine whether two datetimes were within 24h of each other,
> getting confused by what was happening when the two were on different
> sides of
Agreed that having a robust tzinfo object representing "local time,
whatever it is" would be a good feature too. This shouldn't have to
depend on the Olson tz database; it should just consult the libc
localtime function.
--Guido
On Mon, Jun 4, 2012 at 11:30 AM, Alexander Belopolsky
wrote:
> On M
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum wrote:
> A big +1 on making conversions between POSIX timestamps and datetime
> (with or without timezone) easier.
I am all for achieving this goal, but I think the root of the problem
is not the lack of mxDT's ticks() method. Note that someone wh
On Mon, Jun 4, 2012 at 8:51 AM, Barry Warsaw wrote:
> On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
>
>>Personally, I would really like not having to think about the time
>>module at all, except if I wanted to go low-level (e.g. get a Unix
>>timestamp from scratch).
>
> +1
>
> Oh and, pract
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
>Personally, I would really like not having to think about the time
>module at all, except if I wanted to go low-level (e.g. get a Unix
>timestamp from scratch).
+1
Oh and, practicality beats purity.
-Barry
___
On Jun 04, 2012, at 01:19 PM, Dirkjan Ochtman wrote:
>I recently opened issue14908. At work, I have to do a bunch of things
>with dates, times and timezones, and sometimes Unix timestamps are
>also involved (largely for easy compatibility with legacy APIs). I
>find the relative obscurity when conv
On Mon, Jun 4, 2012 at 10:18 PM, Dirkjan Ochtman wrote:
> Can you define "relative time" here? The term makes me think of things
> like timedelta.
Timeouts, performance measurement, that kind of thing. Mostly
timescales of less than an hour, and usually less than a minute.
> Personally, I would
On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan wrote:
> My perspective is that if I'm dealing with strictly absolute time, I
> should only need one import: datetime
>
> If I'm dealing strictly with relative time, I should also only need
> one import: time
Can you define "relative time" here? The te
On Mon, Jun 4, 2012 at 9:19 PM, Dirkjan Ochtman wrote:
> Anyway, I was pointed to issue 2736, which seems to have got a lot of
> discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
> name just a few) up against Alexander (the datetime maintainer,
> AFAIK). It seems like a fairly
35 matches
Mail list logo
