On 09/01/2014 01:27, Roy Smith wrote:
In article <laknps$umv$1...@dont-email.me>,
Kevin Walzer <k...@codebykevin.com> wrote:
I haven't updated my Python apps to 3.x because there's nothing in 3.x
that offers benefits to my users.
I almost found a reason to move to Python 3 today. Then I got smacked.
I had a datetime. I needed a unix timestamp. People need to go back
and forth between these two things all the time and in Python 2 it's the
very definition of impedance mismatch. What should be a dead simple
operation involves long threads on stackoverflow discussing which of
several amalgamations of duct tape is the least ugly.
Anyway, I discovered that Python 3.3's datetime has a .timestamp()
method. Yeah. Finally. Exactly what the world had needed for years.
Then I kept reading and found:
Note: There is no method to obtain the POSIX timestamp directly from a
naive datetime instance representing UTC time.
Ugh. So, we're back to square one. They go on to suggest one of two
workarounds, either calling datetime.replace() to insert a timezone, or
subtracting from the epoch manually.
Naive datetimes are what everybody uses. It's what utcnow() gives you.
So why make life difficult for everybody? Python 3 didn't win a convert
today.
Yep, dates and times are easy. That's why there are 17 issues open on
the bug tracker referencing tzinfo alone. Poor old 1100942 is high
priority, was created 12/01/2005 and has missed 3.4. So if it gets into
3.5 it'll have already celebrated its 10th birthday. It doesn't say
much for the amount of effort that we put into looking after issues.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
