On Tue, Jun 12, 2012 at 1:14 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
To the contrary, without the POSIX timestamp model to define the
equivalency between the same point in time expressed using different
timezones, sane comparisons and arithmetic on timestamps would be
impossible.
On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum gu...@python.org wrote:
On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
..
t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0))
for i in range(5):
... print(strftime(%T%z, localtime(t + i - 2)))
...
On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum gu...@python.org wrote:
On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
..
t = mktime((2010, 11, 7, 1, 0, 0,
On Mon, 11 Jun 2012 10:01:57 -0700, Guido van Rossum gu...@python.org wrote:
On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum gu...@python.org wrote:
On Fri, Jun 8, 2012 at 2:08 PM, Alexander
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
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
Alexander Belopolsky alexander.belopol...@gmail.com writes:
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
On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Alexander Belopolsky alexander.belopol...@gmail.com writes:
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
Guido van Rossum gu...@python.org writes:
On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
Unambiguous storage of absolute time can be achieved with POSIX
timestamps, but that is certainly not the only nor best way to do
it.
For example, RFC 5322
On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum gu...@python.org wrote:
See http://bugs.python.org/issue9527 .
With datetime.timestamp() method committed, I would like to get back
to this issue. In some sense, an inverse of datetime.timestamp() is
missing from the datetime module. Given a
On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum gu...@python.org wrote:
See http://bugs.python.org/issue9527 .
With datetime.timestamp() method committed, I would like to get back
to this issue.
What
MRAB pyt...@mrabarnett.plus.com writes:
datetime objects would consist of the UTC time, time zone and DST.
“time zone” information always entails DST information doesn't it? It
isn't proper time zone information if it doesn't tell you about DST.
That is, when you know the full time zone
Just to add my 2 cents to this discussion as someone who's worked
with mxDateTime for almost 15 years.
I think we all agree that users of an application want to input
date/time data using their local time (which may very well not be
the timezone of the system running the application). On output
On Tue, Jun 5, 2012 at 11:29 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
Changing subject to reflect a change of topic.
On Tue, Jun 5, 2012 at 2:19 PM, Guido van Rossum gu...@python.org wrote:
.. Although if we ever get that local time tzinfo
object, we may regret it. So I
On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum gu...@python.org wrote:
I've also been arguing against local time tzinfo
Why? I don't see your argumentation against such a tzinfo in the bug
See http://bugs.python.org/issue9063 .
The problem is again the DST ambiguity. One day a year,
On Tue, Jun 5, 2012 at 3:33 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 6:07 PM, Guido van Rossum gu...@python.org wrote:
I've also been arguing against local time tzinfo
Why? I don't see your argumentation against such a tzinfo in the bug
See
On Tue, Jun 5, 2012 at 6:49 PM, Guido van Rossum gu...@python.org wrote:
The problem is again the DST ambiguity. One day a year, datetime(y,
m, d, 1, 30, tzinfo=Local) represents two different times and another
day it represents no valid time. Many applications can ignore this
problem but
On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote:
The second feature has its uses. If I want wake up at 7 AM every
weekday, I don't want my alarm clock ask me whether I mean standard or
daylight saving time, but if I attempt to set it to 1:30 AM on the day
when 1:30 AM happens twice, I
On Wed, Jun 6, 2012 at 10:18 AM, Barry Warsaw ba...@python.org wrote:
On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote:
The second feature has its uses. If I want wake up at 7 AM every
weekday, I don't want my alarm clock ask me whether I mean standard or
daylight saving time, but if I
On Tue, Jun 5, 2012 at 8:18 PM, Barry Warsaw ba...@python.org wrote:
I think stdlib should allow me to write
a robust application that knows that some naive datetime objects
correspond to two points in time and some correspond to none.
Really? Why would naive datetimes know that? I would
Le Jun 5, 2012 à 6:16 PM, Nick Coghlan a écrit :
Personally, I'd like to see the datetime module make an explicit
assumption that all naive datetime objects are considered to be UTC,
with the interactions between naive and aware objects updated
accordingly
I would absolutely love it if this
On Tue, Jun 5, 2012 at 9:16 PM, Nick Coghlan ncogh...@gmail.com wrote:
... Local time should only be used for displaying
dates and times to humans (since we care about little things like
local sunrise and sunset, local business hours, etc) and for
inter-system coordination where such details
Alexander Belopolsky wrote:
The problem is again the DST ambiguity. One day a year, datetime(y,
m, d, 1, 30, tzinfo=Local) represents two different times and another
day it represents no valid time.
The documentation example (fixed in issue 9063) addresses the
ambiguity by defaulting to
On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
What would be so bad about giving datetime objects
a DST flag? Apps that don't care could ignore it and
get results no worse than the status quo.
This would neatly solve the round-trip problem, but will open a
On Tue, 05 Jun 2012 18:31:20 -0700, Glyph gl...@twistedmatrix.com wrote:
Le Jun 5, 2012 à 6:16 PM, Nick Coghlan a écrit :
Personally, I'd like to see the datetime module make an explicit
assumption that all naive datetime objects are considered to be UTC,
with the interactions between
On Wed, Jun 6, 2012 at 11:57 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
What would be so bad about giving datetime objects
a DST flag? Apps that don't care could ignore it and
get results no
On Tue, Jun 5, 2012 at 7:44 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Jun 6, 2012 at 11:57 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
What would be so bad about giving datetime objects
On Tue, Jun 5, 2012 at 6:39 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Tue, Jun 5, 2012 at 9:16 PM, Nick Coghlan ncogh...@gmail.com wrote:
... Local time should only be used for displaying
dates and times to humans (since we care about little things like
local sunrise
On Tue, Jun 5, 2012 at 6:31 PM, Glyph gl...@twistedmatrix.com wrote:
Le Jun 5, 2012 à 6:16 PM, Nick Coghlan a écrit :
Personally, I'd like to see the datetime module make an explicit
assumption that all naive datetime objects are considered to be UTC,
with the interactions between naive and
On 06/06/2012 02:57, Alexander Belopolsky wrote:
On Tue, Jun 5, 2012 at 7:11 PM, Greg Ewinggreg.ew...@canterbury.ac.nz wrote:
What would be so bad about giving datetime objects
a DST flag? Apps that don't care could ignore it and
get results no worse than the status quo.
This would neatly
On Wed, Jun 6, 2012 at 1:14 PM, Guido van Rossum gu...@python.org wrote:
You can try to enforce this, but users will ignore it, and happily
represent local time as UTC. I've seen people do this with POSIX
timestamps too -- use the UTC conversions between timestamps and time
tuples, and yet use
On Tue, Jun 5, 2012 at 8:41 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Jun 6, 2012 at 1:14 PM, Guido van Rossum gu...@python.org wrote:
You can try to enforce this, but users will ignore it, and happily
represent local time as UTC. I've seen people do this with POSIX
timestamps too --
32 matches
Mail list logo
