[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Daniel Diniz]

Daniel Diniz  added the comment:

Confirmed for 3.11 in Windows. 

The C datetime code can be trivially fixed so your equality test returns True, 
but there are two Python tests that depend on current behavior so it might not 
be so easy. They were added with current code in issue 24773, to implement PEP 
495 -- Local Time Disambiguation.

Also, using a timezone implementation from the test suite makes the equality 
work, so maybe the bug depends on zoneinfo.

If you change datetimemodule.c line 5761 from "diff = 1;" to "diff = 0;", two 
tests fail and your code works.

See attached file for the tests that fail and using the timezone implementation 
mentioned above.

--
nosy: +ajaksu2
Added file: https://bugs.python.org/file50517/dt_equality.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Huon Wilson]

New submission from Huon Wilson :

The documentation suggests that two datetimes that represent the same moment 
should compare equal, even if they have different timezones: "If both 
comparands are aware and have different tzinfo attributes, the comparands are 
first adjusted by subtracting their UTC offsets (obtained from 
self.utcoffset())." (below 
https://docs.python.org/3/library/datetime.html#datetime.datetime.fold)

This doesn't seem to be true for == with ZoneInfo timezones, even though it is 
true for <= and >=, and -, meaning these seem to violate mathematical 
laws/expectations:

from zoneinfo import ZoneInfo
from datetime import datetime, timezone

dt_utc = datetime(2020, 11, 1, 8, tzinfo=timezone.utc)
dt_local = dt_utc.astimezone(ZoneInfo("America/Los_Angeles"))
print(f"{dt_local == dt_utc = }")
print(f"{dt_local <= dt_utc = }")
print(f"{dt_local >= dt_utc = }")
print(f"{dt_local - dt_utc = }")

Output:

dt_local == dt_utc = False
dt_local <= dt_utc = True
dt_local >= dt_utc = True
dt_local - dt_utc = datetime.timedelta(0)

Tested with:

- macOS 11.4; Python 3.9.7, 3.10.1, 3.11.0a3
- Linux; via docker image python:3.9.7

Full test including comparisons to python-dateutil (same behaviour as ZoneInfo) 
and pytz (== gives True as expected) is attached.

Comparing timestamps for exact equality is potentially unusual, but we use it 
extensively in tests for some time-handling functions.

--
components: Library (Lib)
files: tz.py
messages: 409113
nosy: huonw
priority: normal
severity: normal
status: open
title: Same-moment datetimes with different ZoneInfo timezones are not 
considered ==
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50516/tz.py

___
Python tracker 
<https://bugs.python.org/issue46169>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19065] sqlite3 timestamp adapter chokes on timezones

[Ian Fisher]

Change by Ian Fisher :


--
nosy: +iafisher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25963] strptime not parsing some timezones

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I'm closing this as fixed, the note in datetime docs is here:

https://docs.python.org/3.9/library/datetime.html

(search for 'only accepts', - note 6)

--
nosy: +kj
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25963] strptime not parsing some timezones

[Andrei Kulakov]

Andrei Kulakov  added the comment:

This was fixed so can be closed.

Current datetime docs have a footnote for %Z:

...
strptime() only accepts certain values for %Z:

any value in time.tzname for your machine’s locale

the hard-coded values UTC and GMT

--
nosy: +andrei.avk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43237] datetime.__eq__ returns true when timezones don't match

[Mark Dickinson]

Mark Dickinson  added the comment:

I'm going to close here. While changing the behaviour isn't completely out of 
the question, it would need (a) a clear proposal on how to deal with order 
comparisons and backwards compatibility, and (b) strong support from the 
community. A PEP is probably the best way forward, for anyone who wants to go 
this route.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43237] datetime.__eq__ returns true when timezones don't match

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +belopolsky, p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43237] datetime.__eq__ returns true when timezones don't match

[Mark Dickinson]

Mark Dickinson  added the comment:

Hi Richard. Thanks for the report. Python's working as designed (and as 
documented and tested) here. IOW, the behaviour is deliberate - this isn't a 
bug.

Any change in behaviour would have to target 3.10 at the earliest (and it's 
already quite late in the release process for 3.10). A couple of questions: (1) 
what would you want the comparisons `datetime_in_sgt <= datetime_in_utc` and 
`datetime_in_utc <= datetime_in_sgt` to give? (2) How would you propose to 
change the behaviour without breaking existing code that makes use of the 
current behaviour?

> This is confusing and non-intuitive.

That's a rather subjective judgement. I'd personally find the behaviour you 
suggest non-intuitive (and I find the behaviour of Java's order comparisons on 
ZonedDateTime to be highly non-intuitive). We'd need something a bit more 
objective and/or widely supported to justify a behaviour change.

--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43237] datetime.__eq__ returns true when timezones don't match

[Richard Wise]

New submission from Richard Wise :

from datetime import datetime, timezone, timedelta

datetime_in_sgt = datetime(2021, 2, 16, 8, 0, 0, 
tzinfo=timezone(timedelta(hours=8)))
datetime_in_utc = datetime(2021, 2, 16, 0, 0, 0, tzinfo=timezone.utc)

print(datetime_in_sgt == datetime_in_utc)

Expected: False
Actual: True

Although these two datetimes represent the same instant on the timeline, they 
are not identical because they use different timezones. This means that when 
unit testing timezone handling, tests will incorrectly pass despite data being 
returned in UTC instead of the requested timezone, so we need to write code 
such as this:

# Timestamp comparison
self.assertEqual(datetime_in_sgt, datetime_in_utc)
# Timezone comparison
self.assertEqual(datetime_in_sgt.tzinfo, datetime_in_utc.tzinfo)

This is confusing and non-intuitive.

For examples of how other languages handle such comparison, can refer to: 
https://docs.oracle.com/javase/8/docs/api/java/time/ZonedDateTime.html#equals-java.lang.Object-
 and 
https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html#equals-java.lang.Object-

--
components: Library (Lib)
messages: 387087
nosy: Woodz
priority: normal
severity: normal
status: open
title: datetime.__eq__ returns true when timezones don't match
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue43237>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25963] strptime not parsing some timezones

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[DL Neil via Python-list]

On 13/02/20 9:17 AM, Michael Torrie wrote:

On 2/12/20 7:44 AM, Ethan Furman wrote:

On 02/11/2020 04:38 PM, Michael Torrie wrote:

...


True.  Costs can be calculated and planned for. But Technical debt is
often impossible to quantify in a real, meaningful, business sense,
other than the that we "know" it's going to cost big time in the future.
  In some senses, it's theoretical future cost.  That's what I was having
a hard time with, and still do to a large degree.


I think an oft overlooked aspect of technical debt is the affect on
the programmers dealing with it:  frustration, burn-out, and
job-seeking.


Yeah for sure.  A programmer may not love dealing with technical debt,
and certainly he may want to chase greener fields.  But there are lots
of things about lots of jobs that are less pleasant than other things.
Personally I tend to get way caught up trying to get a perfect design
that avoids technical debt, but often get not much done (on my personal
projects). Whereas another guy just cranks out code that isn't always
the best but serves his needs at the time. Guess who is more productive
overall? Not me.


Applauding your professional attitude, but haven't you (only) defined 
"productive" as purely getting 'this job' out the door? cf any 
definition of "Total" cost?



I had an IT Manager moaning at me precisely because of one of those 
'other guys'. The job had been 'done'. The contract had mere 'words' to 
cover 'quality'. Accordingly, difficult to argue that 'the guy' hadn't 
done what was asked (my 'specialist' $advice on the matter). However, 
the code was 'ramshackle' and had obviously been 'dashed off' in the 
shortest amount of time possible. Maintenance costs were expected to be 
high; motivation of in-house staff to do so, expected to be v.low!


So, we're re-negotiating the contract-wording... More importantly, 
improving their acceptance testing, and adding more detail to their 
specs/requirements, etc. (the mistake there, was thinking that reqmts to 
external staff would be 'the same' as such to in-house employees)



However, the interesting question was to ask whether he (the manager) 
was 'taking advantage' of the "gig economy". (yes, that's what it's 
there for!) Thus, what relationship did he (or even, 'they' of the IT 
dept) have with the contractor? The home truth: 'using' the cheapest 
people creates a 'race to the bottom', and must, by definition, lead to 
'the cheapest job' being done. Why the surprise?
(He doesn't hire me as a programmer - and we're not even talking 
'Python', apologies!)


I asked him if he wanted a 'professional' to do the job, ie in a 
'professional manner'. Yes! So, why are you looking for the guy(?) 
who'll do it at the lowest-possible price/rate or imposing the delivery 
date on a short time-line? Ahh...


The above concerns contractors, but I managed to slide-in a few 
questions/comments that relationships with in-house staff require 
similar consideration and attention!




OK, so turning it around to people more like 'us': Professionalism? As a 
programmer/coder, would you rather work on decent code? So, is that what 
you turn-out? Alternatively, vice-versa.


That is a slightly unfair, or biased, question. I am in the fortunate 
position of being able to tell certain people that I won't undertake 
their work, that where they want me to work will push the price UP, that 
their tool-set is sub-standard, or that the existing platform is imbued 
with uncomfortably high 'risk'. I quite understand that someone who 
'needs the job' will see that as a 'luxury'. (apologies as necessary)


That said, would you build a team with a mixture of 'clock-watchers' and 
'professionals' or would/do you enjoy working within such a team?


Both 'sides' need to understand that there are two view-points to every 
relationship.



One thought that occurred to me lurking/reading this thread, is the 
likelihood that many of the differing views arise between those working 
in an 'Agile' environment, and those not (or a pseudo-/'we call 
it'-Agile environment)?


One of the (social) contracts in Scrum (for example) is that the 
professionals estimate the time needed to do the job, cf some (likely 
ignorant) 'manager' imposing a deadline. In my experience (YMMV) an 
established, professional 'Agile' team tends to follow practices which 
attempt to avoid adding to Technical Debt, and factor-in any need to 
correct sub-standard or sans-tests old-code. There is no doubt in my 
mind, that the participation of 'users' helps to create an understanding 
that (like anything else) software takes time (read also $), and that 
over-loading (?abusing) development staff is itself a 'Technical Debt' 
("Marginal Cost") for the organisation! (absences, turn-over, ... you've 
been-there, seen-that...). There again, would user-members of the team 
notice if 'we'd' padded our estimates so as to have plenty of time for 
'other things'?


It's by no means a cut-and-dried situation. What 

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/12/20 7:44 AM, Ethan Furman wrote:
> On 02/11/2020 04:38 PM, Michael Torrie wrote:
> 
>> It's all just different ways of accounting for the same things. In
>> the olden days before the term "technical debt" was invented, we
>> called this "total cost of ownership."
> 
> TCO is not a fixed number.  For example, if a loan is taken to help
> fund a project, then the "interest debt" will be a portion of the
> TCO, but its amount will vary depending on the interest rate: 15%
> will be more interest debt than 4%.  Likewise, the technical debt for
> a project will be higher or lower depending on the quality of the
> code written.

True.  Costs can be calculated and planned for. But Technical debt is
often impossible to quantify in a real, meaningful, business sense,
other than the that we "know" it's going to cost big time in the future.
 In some senses, it's theoretical future cost.  That's what I was having
a hard time with, and still do to a large degree.

> I think an oft overlooked aspect of technical debt is the affect on
> the programmers dealing with it:  frustration, burn-out, and
> job-seeking.

Yeah for sure.  A programmer may not love dealing with technical debt,
and certainly he may want to chase greener fields.  But there are lots
of things about lots of jobs that are less pleasant than other things.
Personally I tend to get way caught up trying to get a perfect design
that avoids technical debt, but often get not much done (on my personal
projects). Whereas another guy just cranks out code that isn't always
the best but serves his needs at the time. Guess who is more productive
overall? Not me.

More on topic, I feel like the technical debt issue might be over used
to push folks to upgrade from Python 2, or to do promote certain
technologies.

Without knowing the details of how and why they used it, it's impossible
for me to say that it will cost them a lot in the future.  It very well
could cost nothing.  Or it might be expensive enough to sink an enterprise.

In the case of the original poster, it could well be that the
maintenance he's doing to the code is minor and of no real cost, nor any
maintenance burden in the future.  He might not need security patches or
any other on-going development of the Python 2 interpreter.  His app
might have no attack surface.  The script does its internal job and
that's that.  As long as a Python2 interpreter runs he's golden. I
suspect a lot of Python 2 use falls into that sort of category.  Sort of
like the company I know that still uses an MS-DOS billing system.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Rhodri James]

On 12/02/2020 17:46, Python wrote:

On Wed, Feb 12, 2020 at 01:16:03PM +, Rhodri James wrote:

On 12/02/2020 00:53, Python wrote:

In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible, and management prefers to underfund the work
than to overfund it, for cost-savings reasons.  This basically means
that any non-trivial work you do inevitably will become technical debt



s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
creates debt (or future headaches, if you prefer to think of it that way).



I think it's a purely semantic distinction without a practical
difference...which was the point I was trying to make.  The work is
the direct cause of the debt, and at the time it is performed the debt
is realized.  Without the work, that particular debt is not incurred.
You may have eliminated some old debt when the work is done, but your
new debt replaces your old debt.  Depending on the resources you can
devote, that debt may or MAY NOT be less than the other, and sometimes
the truth of this can not be discovered until you're already knee deep
in it.


Here's where the "purely semantic" distinction matters.  You are 
equating the work with the debt, but ignoring the benefit the work 
presumably brings (otherwise you wouldn't have done it at all).  Either 
you should be rolling it all together or separate both, surely.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Wed, Feb 12, 2020 at 01:16:03PM +, Rhodri James wrote:
> On 12/02/2020 00:53, Python wrote:
> > In pretty much every job I've ever worked at, funding work (e.g. with
> > humans to do it) with exactly and precisely the resources required is
> > basically impossible, and management prefers to underfund the work
> > than to overfund it, for cost-savings reasons.  This basically means
> > that any non-trivial work you do inevitably will become technical debt
> 
> s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
> creates debt (or future headaches, if you prefer to think of it that way).

I think it's a purely semantic distinction without a practical
difference...which was the point I was trying to make.  The work is
the direct cause of the debt, and at the time it is performed the debt
is realized.  Without the work, that particular debt is not incurred.
You may have eliminated some old debt when the work is done, but your
new debt replaces your old debt.  Depending on the resources you can
devote, that debt may or MAY NOT be less than the other, and sometimes
the truth of this can not be discovered until you're already knee deep
in it.

> > So conceptually "costs" may be different from "debt" but in
> > practice, you never have one without the other, and "debt" is
> > really just "costs" you haven't paid yet.
> 
> It's that last bit, "you haven't paid yet", that's the important part.
> Project managers and accountants alike are very much in favour of putting
> off paying for things if they can.  Sometimes they can be persuaded that the
> interest on the debt (the extra cost that the code structure imposes on
> fixing bugs) is too much, and then you get the opportunity to refactor and
> reduce the overall debt (at a cost, obviously) and the interest you will pay
> in the future.

Right.  Or... not.  More often than not, in my experience.  And
sometimes you can convince them you need to, but other priorities
continually surface that block it from ever happening anyway.
 
> Sometimes, and this is the bit that bean counters really like, you can get
> away without paying the debt by ditching the project entirely before the
> debt is paid off.  If you don't want to piss your customers off you need to
> pay the cost of a replacement project, which will accrue its own technical
> debt...

Or it may become obsolete due to changing circumstances.  Or (as in
many cases) it is sufficient to tell your customers, "don't do that,"
perhaps with admittedly annoying but not particularly costly
consequences if they don't listen. :) 

[It's not always feasible, but often if they complain, you can say
something like, "...but we're working on this other magic thingy that
will really help you, and spending time on fixing this thing you're
complaining about now will significantly delay the delivery of that."
It may or may not be true, but in the interim the customer learns to
stop doing that thing, and forgets they ever cared.]

Technical debt is just about inevitable, for most non-trivial software
(again, unless you've got a special case of a full solution for some
problem whose circumstances never change), and isn't necessarily a bad
thing.  It just depends entirely on the details of your situation.
And while I'm not particularly a fan of Agile in practice, the
philosophy behind it addresses this reasonably well...  But then
again, you don't *need* Agile to do that, either.  You just have to
pay attention to the problem.  Like everything else.

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Avi Gross via Python-list]

I have to wonder if this is a bit like what happens when something like
Windows offers you an upgrade if you pay for it. Some people have noticed
how after such things come out, a series of rapid bug fixes come along. So,
they wait. Some wait long enough until another entire version has come along
or even several such cycles. They then try to jump from say version 2.1 to
version 5.0 and skip paying for all the in-betweens. Others may wait till
something forces them to change like receiving documents their version of
EXCEL cannot handle properly or at all. And, when that happens, they may
simply jump to a different product entirely, like leaving Lotus for EXCEL.

And, as noted, some simply move on. All kinds of calendar programs and
contact list managers can become obsolete when it is all bundled into
something like Microsoft office Outlook. At some point, you toss the old or
use some tool to migrate your data, or start over.

With your own software a migration can be hairy and especially when the
original staff are long gone or promoted and the manager has no clue and no
budget for this. There seems to be substantial risk versus just leaving it
alone and hoping it works long enough for you to get your bonus or move on.
It is worse if the people maintaining it sort of made their own kludge
variations like reinventing new features on their own in ways not compatible
with the new. Do you port the kludge or switch over to the new way even if
it means restructuring other parts of the code.

A serious question. What has happened in other aspects of the field where a
big enough change bifurcates the community? I am wondering what happened
when PERL made incompatible changes. Are people still using both versions?
What about largely discontinued languages that stopped being developed in
any way and do not even have a compiler for newer machines?

I know Microsoft periodically declares no further support for much earlier
versions of Windows. I bet people who have old machines keep running without
an upgrade, especially when their machine does not support the new version
because it does not have enough memory or whatever. Why keep the old? I am
sure they have their reasons that boil down to it runs programs they know
well and that do what they need and do not add many bells and whistles that
they  don't think they need or that force them to change their ways. For
some touch typists, the earlier word processors that do not know about a
mouse and run in one big window, may be just right. But try sending one to
others without using some conversion method first.

But anyone teaching Python today who still uses version 2 exclusively may
have some explaining to do unless the goal is to maintain and migrate those
using it to version 3. Are there any serious new projects being built NOW
using version 2?

-Original Message-
From: Python-list  On
Behalf Of Rhodri James
Sent: Wednesday, February 12, 2020 8:16 AM
To: python-list@python.org
Subject: Re: Technical debt - was Re: datetime seems to be broken WRT
timezones (even when you add them)

On 12/02/2020 00:53, Python wrote:
> In pretty much every job I've ever worked at, funding work (e.g. with 
> humans to do it) with exactly and precisely the resources required is 
> basically impossible, and management prefers to underfund the work 
> than to overfund it, for cost-savings reasons.  This basically means 
> that any non-trivial work you do inevitably will become technical debt

s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
creates debt (or future headaches, if you prefer to think of it that way).

> IMMEDIATELY, because you will not be given the time to do the job 
> completely in the first place, there will inevitably be bugs which are 
> minor enough to ignore indefinitely, and most likely, in order to meet 
> arbitrary-but-nevertheless-real time constraints you will find 
> yourself obliged to take shortcuts.  So conceptually "costs" may be 
> different from "debt" but in practice, you never have one without the 
> other, and "debt" is really just "costs" you haven't paid yet.

It's that last bit, "you haven't paid yet", that's the important part. 
Project managers and accountants alike are very much in favour of putting
off paying for things if they can.  Sometimes they can be persuaded that the
interest on the debt (the extra cost that the code structure imposes on
fixing bugs) is too much, and then you get the opportunity to refactor and
reduce the overall debt (at a cost,
obviously) and the interest you will pay in the future.

Sometimes, and this is the bit that bean counters really like, you can get
away without paying the debt by ditching the project entirely before the
debt is paid off.  If you don't want to piss your customers off you need to
pay the cost of a replacement project, which will accrue its own technical
debt...

-- 
Rhodri Jam

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Ethan Furman]

On 02/11/2020 04:38 PM, Michael Torrie wrote:


It's all just different ways of accounting for the same things. In the
olden days before the term "technical debt" was invented, we called this
"total cost of ownership."


TCO is not a fixed number.  For example, if a loan is taken to help fund a project, then 
the "interest debt" will be a portion of the TCO, but its amount will vary 
depending on the interest rate: 15% will be more interest debt than 4%.  Likewise, the 
technical debt for a project will be higher or lower depending on the quality of the code 
written.

I think an oft overlooked aspect of technical debt is the affect on the 
programmers dealing with it:  frustration, burn-out, and job-seeking.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Rhodri James]

On 12/02/2020 00:53, Python wrote:

In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible, and management prefers to underfund the work
than to overfund it, for cost-savings reasons.  This basically means
that any non-trivial work you do inevitably will become technical debt


s/become/accrue/.  The work itself isn't the debt, but its 
sub-optimality creates debt (or future headaches, if you prefer to think 
of it that way).



IMMEDIATELY, because you will not be given the time to do the job
completely in the first place, there will inevitably be bugs which are
minor enough to ignore indefinitely, and most likely, in order to meet
arbitrary-but-nevertheless-real time constraints you will find
yourself obliged to take shortcuts.  So conceptually "costs" may be
different from "debt" but in practice, you never have one without the
other, and "debt" is really just "costs" you haven't paid yet.


It's that last bit, "you haven't paid yet", that's the important part. 
Project managers and accountants alike are very much in favour of 
putting off paying for things if they can.  Sometimes they can be 
persuaded that the interest on the debt (the extra cost that the code 
structure imposes on fixing bugs) is too much, and then you get the 
opportunity to refactor and reduce the overall debt (at a cost, 
obviously) and the interest you will pay in the future.


Sometimes, and this is the bit that bean counters really like, you can 
get away without paying the debt by ditching the project entirely before 
the debt is paid off.  If you don't want to piss your customers off you 
need to pay the cost of a replacement project, which will accrue its own 
technical debt...


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Jon Ribbens via Python-list]

On 2020-02-12, Chris Angelico  wrote:
> But you CAN rewrite code such that it reduces technical debt. You can
> refactor code to make it more logical.

... but if doing so costs more than the debt, you shouldn't do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 12:32 PM Michael Torrie  wrote:
>
> On 2/11/20 6:15 PM, Chris Angelico wrote:
> > On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie  wrote:
> >>
> >> On 2/11/20 5:55 PM, Chris Angelico wrote:
> >>> But you CAN rewrite code such that it reduces technical debt. You can
> >>> refactor code to make it more logical. You can update things to use
> >>> idioms that better express the concepts you're trying to represent
> >>> (maybe because those idioms require syntactic features that didn't
> >>> exist, or simply because you didn't know about them when you first
> >>> wrote the code). Maybe you'll still have SOME debt, but that doesn't
> >>> mean it's never reduced.
> >>>
> >>> Debt is not a binary state.
> >>
> >> I agree with that. But your reply to my other comment didn't say that.
> >> it said "it CAN be paid off" which is a binary thing.  Debt is paid off
> >> (no longer existing) or it's not.  Debt can be paid down and reduced of
> >> course.
> >
> > Ahh, that might be a regional difference then, because around here,
> > it's possible to pay off some of a debt. That would be why we were
> > talking past each other.
>
> Yup I just came to that conclusion while typing a reply to your other
> post!  My apologies.
>

My apologies also :) It was one of those weird situations where I was
all "oh come on, he doesn't SERIOUSLY think that you never get rid of
any tech debt?" and you were all "oh come on, he doesn't SERIOUSLY
think that you can get rid of all of it", and we just both had no idea
:)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 6:15 PM, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie  wrote:
>>
>> On 2/11/20 5:55 PM, Chris Angelico wrote:
>>> But you CAN rewrite code such that it reduces technical debt. You can
>>> refactor code to make it more logical. You can update things to use
>>> idioms that better express the concepts you're trying to represent
>>> (maybe because those idioms require syntactic features that didn't
>>> exist, or simply because you didn't know about them when you first
>>> wrote the code). Maybe you'll still have SOME debt, but that doesn't
>>> mean it's never reduced.
>>>
>>> Debt is not a binary state.
>>
>> I agree with that. But your reply to my other comment didn't say that.
>> it said "it CAN be paid off" which is a binary thing.  Debt is paid off
>> (no longer existing) or it's not.  Debt can be paid down and reduced of
>> course.
> 
> Ahh, that might be a regional difference then, because around here,
> it's possible to pay off some of a debt. That would be why we were
> talking past each other.

Yup I just came to that conclusion while typing a reply to your other
post!  My apologies.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 5:53 PM, Python wrote:
> If your hypothetical project was implemented perfectly from the
> beginning, in Python2.x, it may never need updating, and therefore
> there may well never be any reason to port it to python3.  So doing so
> would be neither "debt" nor "cost" but rather "waste."

I would agree generally, except eventually Python2 will be unavailable
in your distro and may no longer be build-able on current OS's.  However
if the program is working as well as you state, then the cost of
converting to the current version of Python (whatever that will be) is
not going to increase significantly.  Whatever the case, technical debt
belongs to the entity that owns the code.

I know some folks still running an MS-DOS system for billing.  Thanks to
things like DosBox, this system will live on for a long time yet. It
works, and they don't have any real need for anything beyond it.  It's
never needed much updating or maintenance beyond maintenance they would
do anyway like backups.  Insane amounts of technical debt?  Maybe.  Or
maybe just the cost of buying a new off-the-shelf system, which would be
the same cost (or more likely a lot more with upgrades and service
plans) had they done this years ago.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie  wrote:
>
> On 2/11/20 5:55 PM, Chris Angelico wrote:
> > But you CAN rewrite code such that it reduces technical debt. You can
> > refactor code to make it more logical. You can update things to use
> > idioms that better express the concepts you're trying to represent
> > (maybe because those idioms require syntactic features that didn't
> > exist, or simply because you didn't know about them when you first
> > wrote the code). Maybe you'll still have SOME debt, but that doesn't
> > mean it's never reduced.
> >
> > Debt is not a binary state.
>
> I agree with that. But your reply to my other comment didn't say that.
> it said "it CAN be paid off" which is a binary thing.  Debt is paid off
> (no longer existing) or it's not.  Debt can be paid down and reduced of
> course.

Ahh, that might be a regional difference then, because around here,
it's possible to pay off some of a debt. That would be why we were
talking past each other.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 5:55 PM, Chris Angelico wrote:
> But you CAN rewrite code such that it reduces technical debt. You can
> refactor code to make it more logical. You can update things to use
> idioms that better express the concepts you're trying to represent
> (maybe because those idioms require syntactic features that didn't
> exist, or simply because you didn't know about them when you first
> wrote the code). Maybe you'll still have SOME debt, but that doesn't
> mean it's never reduced.
> 
> Debt is not a binary state.

I agree with that. But your reply to my other comment didn't say that.
it said "it CAN be paid off" which is a binary thing.  Debt is paid off
(no longer existing) or it's not.  Debt can be paid down and reduced of
course.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 12:00 PM Michael Torrie  wrote:
>
> On 2/11/20 5:42 PM, Chris Angelico wrote:
> > Yes, if you consider the term to be synonymous with TCO, then
> > naturally you'll see it as useless. But it isn't. Technical debt is a
> > very specific thing and it CAN be paid off.
>
> We'll agree to disagree on the last bit. And I'm not the only one that
> believes technical debt can never be paid off.  Microsoft got fabulously
> wealthy incurring vast amounts of technical debt.  We can argue that
> Windows is the result (it is), but what's killing Windows isn't the
> technical debt. It's the cloud and the web.

So what you're showing is that, sometimes, technical debt isn't paid
off. It's a bit of a logical leap to go from there to "technical debt
CAN'T be paid off", don't you think?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Terry Reedy]

On 2/11/2020 3:09 PM, Chris Angelico wrote:

What you're talking about is costs in general, but "debt" is a very
specific term. You accrue technical debt whenever you "borrow" time
from the future - doing something that's less effort now at the
expense of being worse in the future.


A prime example is sending code to production without automated tests.


You pay off that debt when you
sink time into something in order to make it easier to work on in the
future.


In May 2013, idlelib had no test suite, no test/test_idle.py, and a few 
non-unittest unit tests.  Coverage is now somewhere around 50% and 
tested modules are much easier to work with.



The most common form of technical debt is legacy code, where
you often end up paying interest on the debt every time you dip your
toes into the code to make a small change, avoiding the work of
actually refactoring things and fixing the problems.


Without automated tests, every little change required manual testing and 
carried a non-zero chance of a regression.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 11:48 AM Michael Torrie  wrote:
>
> On 2/11/20 5:37 PM, Chris Angelico wrote:
> > On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie  wrote:
> >>
> >> On 2/11/20 2:25 PM, Barry Scott wrote:
> >>> At Chris said moving to python3 will *reduce* your technical debt.
> >>> You are paying off the debt.
> >>
> >> While at the same time incurring new debt.
> >
> > That's not an intrinsic part of the rewrite, and will only happen if
> > you do the job sloppily.
> >
> > Perhaps you're completely misunderstanding the meaning of the term?
> >
> > https://en.wikipedia.org/wiki/Technical_debt
> > https://thedailywtf.com/articles/technical-debt
>
> Yes I understand the meaning.  Getting code out the door now, at the
> expense of maintenance later.  But really all code is technical debt.
> That's my main point.  No one writes good enough code to be completely
> free of this technical debt.

But you CAN rewrite code such that it reduces technical debt. You can
refactor code to make it more logical. You can update things to use
idioms that better express the concepts you're trying to represent
(maybe because those idioms require syntactic features that didn't
exist, or simply because you didn't know about them when you first
wrote the code). Maybe you'll still have SOME debt, but that doesn't
mean it's never reduced.

Debt is not a binary state.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 5:42 PM, Chris Angelico wrote:
> Yes, if you consider the term to be synonymous with TCO, then
> naturally you'll see it as useless. But it isn't. Technical debt is a
> very specific thing and it CAN be paid off.

We'll agree to disagree on the last bit. And I'm not the only one that
believes technical debt can never be paid off.  Microsoft got fabulously
wealthy incurring vast amounts of technical debt.  We can argue that
Windows is the result (it is), but what's killing Windows isn't the
technical debt. It's the cloud and the web.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Wed, Feb 12, 2020 at 07:09:12AM +1100, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie  wrote:
> > Speaking about technical debt is certainly fashionable these days.  As
> > if we've somehow discovered a brand new way of looking at things.  But
> > it doesn't matter what you do, there's always real cost, and therefore
> > always technical debt. Moving to Python 3 incurs technical debt.
> > Staying with Python 2 incurs technical debt.  Thus I wonder if the term
> > is actually that useful.
[...]
> What you're talking about is costs in general, but "debt" is a very
> specific term. You accrue technical debt whenever you "borrow" time
> from the future - doing something that's less effort now at the
> expense of being worse in the future.

In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible, and management prefers to underfund the work
than to overfund it, for cost-savings reasons.  This basically means
that any non-trivial work you do inevitably will become technical debt
IMMEDIATELY, because you will not be given the time to do the job
completely in the first place, there will inevitably be bugs which are
minor enough to ignore indefinitely, and most likely, in order to meet
arbitrary-but-nevertheless-real time constraints you will find
yourself obliged to take shortcuts.  So conceptually "costs" may be
different from "debt" but in practice, you never have one without the
other, and "debt" is really just "costs" you haven't paid yet.  

If your hypothetical project was implemented perfectly from the
beginning, in Python2.x, it may never need updating, and therefore
there may well never be any reason to port it to python3.  So doing so
would be neither "debt" nor "cost" but rather "waste."


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 5:37 PM, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie  wrote:
>>
>> On 2/11/20 2:25 PM, Barry Scott wrote:
>>> At Chris said moving to python3 will *reduce* your technical debt.
>>> You are paying off the debt.
>>
>> While at the same time incurring new debt.
> 
> That's not an intrinsic part of the rewrite, and will only happen if
> you do the job sloppily.
> 
> Perhaps you're completely misunderstanding the meaning of the term?
> 
> https://en.wikipedia.org/wiki/Technical_debt
> https://thedailywtf.com/articles/technical-debt

Yes I understand the meaning.  Getting code out the door now, at the
expense of maintenance later.  But really all code is technical debt.
That's my main point.  No one writes good enough code to be completely
free of this technical debt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 11:39 AM Michael Torrie  wrote:
>
> On 2/11/20 1:09 PM, Chris Angelico wrote:
> > What you're talking about is costs in general, but "debt" is a very
> > specific term. You accrue technical debt whenever you "borrow" time
> > from the future - doing something that's less effort now at the
> > expense of being worse in the future. You pay off that debt when you
> > sink time into something in order to make it easier to work on in the
> > future. The most common form of technical debt is legacy code, where
> > you often end up paying interest on the debt every time you dip your
> > toes into the code to make a small change, avoiding the work of
> > actually refactoring things and fixing the problems.
>
> It's all just different ways of accounting for the same things. In the
> olden days before the term "technical debt" was invented, we called this
> "total cost of ownership." This not only included the up front cost, but
> the on-going (and potentially increasing) cost of maintenance, and often
> even the future cost of migrating to a new solution.  So in the end it's
> all the same: cost.  And it's never paid off.  Ever.  That's why I've
> recently come to question the usefulness of the term "technical debt."

Yes, if you consider the term to be synonymous with TCO, then
naturally you'll see it as useless. But it isn't. Technical debt is a
very specific thing and it CAN be paid off.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 1:09 PM, Chris Angelico wrote:
> What you're talking about is costs in general, but "debt" is a very
> specific term. You accrue technical debt whenever you "borrow" time
> from the future - doing something that's less effort now at the
> expense of being worse in the future. You pay off that debt when you
> sink time into something in order to make it easier to work on in the
> future. The most common form of technical debt is legacy code, where
> you often end up paying interest on the debt every time you dip your
> toes into the code to make a small change, avoiding the work of
> actually refactoring things and fixing the problems.

It's all just different ways of accounting for the same things. In the
olden days before the term "technical debt" was invented, we called this
"total cost of ownership." This not only included the up front cost, but
the on-going (and potentially increasing) cost of maintenance, and often
even the future cost of migrating to a new solution.  So in the end it's
all the same: cost.  And it's never paid off.  Ever.  That's why I've
recently come to question the usefulness of the term "technical debt."

> Porting to Python 3 should *improve* your codebase, so it should be a
> way of shedding technical debt. (Unless you do it by running 2to3 on
> your code and hoping for the best. But that's a bad idea for many
> other reasons.)

But see, this is the thing.  There's brand new technical debt accrued
with the move to Python 3.  The cost of the debt is lower, but it's
still there.  Because maintenance is still going to cost.  Versions
still bump and require hopefully minor tweaks.  Eventually the bigger
jumps come. New ideas come along also. New frameworks, new paradigms.


I think it's a fallacy to think we can pay down technical debt.

I'm sure we probably disagree.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie  wrote:
>
> On 2/11/20 2:25 PM, Barry Scott wrote:
> > At Chris said moving to python3 will *reduce* your technical debt.
> > You are paying off the debt.
>
> While at the same time incurring new debt.

That's not an intrinsic part of the rewrite, and will only happen if
you do the job sloppily.

Perhaps you're completely misunderstanding the meaning of the term?

https://en.wikipedia.org/wiki/Technical_debt
https://thedailywtf.com/articles/technical-debt

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 2:25 PM, Barry Scott wrote:
> At Chris said moving to python3 will *reduce* your technical debt.
> You are paying off the debt.

While at the same time incurring new debt.

> Not to mention that its harder to hire people to work on tech-debt legacy 
> code.
> 
> Given the choice between a legacy python2 job and a modern python3 job
> what would you choose?

If this was an income job, it would entirely depend on what it paid.  In
this day and age of the so-called "gig economy" it really doesn't
matter. I likely wouldn't be around long enough to have to personally
deal with the long-term consequences (pay the debt as you say).

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Barry Scott]

> On 11 Feb 2020, at 20:01, Michael Torrie  wrote:
> 
> On 2/11/20 4:05 AM, Chris Angelico wrote:
>> Or just the recognition that, eventually, technical debt has to be
>> paid. 
> 
> Speaking about technical debt is certainly fashionable these days.  As
> if we've somehow discovered a brand new way of looking at things.  But
> it doesn't matter what you do, there's always real cost, and therefore
> always technical debt. Moving to Python 3 incurs technical debt.
> Staying with Python 2 incurs technical debt.  Thus I wonder if the term
> is actually that useful.


At Chris said moving to python3 will *reduce* your technical debt.
You are paying off the debt.


> 
> I know what you mean, though.  The cost of staying with Python2 is
> increasing rapidly compared to the cost of porting to Python3.  Unlike
> the nebulous term, "technical debt," the cost of staying with Python2 vs
> porting to Python3 can be quantified in real dollar amounts.  I've no
> doubt that the calculus is in favor of Python2 a while longer for many
> people.

Not to mention that its harder to hire people to work on tech-debt legacy code.

Given the choice between a legacy python2 job and a modern python3 job
what would you choose?

Barry


> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Barry Scott]

> On 10 Feb 2020, at 23:01, Python  wrote:
> 
> As best I can tell, Python has no means to make use of the system's
> timezone info.  In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the timezone you care about.  In the general
> case, this is hard, but since the timezone my dates are in is always
> GMT, it's no problem:
> 
> class GMT(datetime.tzinfo):
>def utcoffset(self, dt):
>return datetime.timedelta(hours=0)
>def dst(self, dt):
>return datetime.timedelta(minutes=0)
>def tzname(self, dt):
>return "GMT"
> 
> Now, you can instantiate a datetime.datetime object with the times you
> want, and pass an instance of this class as the tzinfo argument to the
> constructor.  Also no problem:


 dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, GMT())
 dt
> datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, tzinfo=<__main__.GMT object 
> at 0x7f9084e2add0>)
 print dt
> 2020-01-31 01:30:45.987654+00:00
> 
> Note the tzinfo object, and the +00:00 indicating this is indeed in
> GMT.  If you create a "naive" datetime object, you don't get that:
> 
 xy = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
 xy
> datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
 print xy
> 2020-01-31 01:30:45.987654
> 
> 
> So far, so good.  However, when you go to use this object, the time it
> represents is in fact wrong.  For example:
> 
 print dt.strftime("%s")
> 1580452245
> 
> Using the date command, we can easily see that it is incorrect:
> 
> # Ask for UTC, gives the wrong time
> $ date -u -d "@1580452245"
> Fri Jan 31 06:30:45 UTC 2020
> 
> # Ask for local time, gives the time I specified... which should have
> # been in GMT, but is in my local timezone
> $ date -d "@1580452245"
> Fri Jan 31 01:30:45 EST 2020
> 
> And the correct value should have been:
> $ date -d "2020-01-31 1:30:45 GMT" +%s
> 1580434245
> 
> Same results under Python2.7 or Python3.
> 
> :( :( :(
> 
> I suspect this is because the underlying implementation uses
> strftime() which takes struct tm, which has no field to contain the
> timezone info, and does not do the necessary conversion before handing
> it off.  I'm not sure what the date command is doing differently, but
> it clearly is able to get the correct answer.
> 
> Does Python have an alternative way to do the above, with correct
> results?

I found that there are two useful PyPi packages to help with time zones.
pytz and tzlocal.

Here is a piece of code that I use to be timezone aware for UTC and the
local time zone. It works for Windows, macOS and unix thanks.

import datetime
import pytz
import tzlocal

def utcDatetime( timestamp ):
return pytz.utc.localize( datetime.datetime.utcfromtimestamp( timestamp ) )

def localDatetime( datetime_or_timestamp ):
if type(datetime_or_timestamp) in (int, float):
dt = utcDatetime( datetime_or_timestamp )
else:
dt = datetime_or_timestamp

local_timezone = tzlocal.get_localzone()
local_dt = dt.astimezone( local_timezone )
return local_dt

Barry



> 
> Thanks
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie  wrote:
>
> On 2/11/20 4:05 AM, Chris Angelico wrote:
> > Or just the recognition that, eventually, technical debt has to be
> > paid.
>
> Speaking about technical debt is certainly fashionable these days.  As
> if we've somehow discovered a brand new way of looking at things.  But
> it doesn't matter what you do, there's always real cost, and therefore
> always technical debt. Moving to Python 3 incurs technical debt.
> Staying with Python 2 incurs technical debt.  Thus I wonder if the term
> is actually that useful.
>
> I know what you mean, though.  The cost of staying with Python2 is
> increasing rapidly compared to the cost of porting to Python3.  Unlike
> the nebulous term, "technical debt," the cost of staying with Python2 vs
> porting to Python3 can be quantified in real dollar amounts.  I've no
> doubt that the calculus is in favor of Python2 a while longer for many
> people.

What you're talking about is costs in general, but "debt" is a very
specific term. You accrue technical debt whenever you "borrow" time
from the future - doing something that's less effort now at the
expense of being worse in the future. You pay off that debt when you
sink time into something in order to make it easier to work on in the
future. The most common form of technical debt is legacy code, where
you often end up paying interest on the debt every time you dip your
toes into the code to make a small change, avoiding the work of
actually refactoring things and fixing the problems.

Porting to Python 3 should *improve* your codebase, so it should be a
way of shedding technical debt. (Unless you do it by running 2to3 on
your code and hoping for the best. But that's a bad idea for many
other reasons.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 6:45 AM Python  wrote:
>
> On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote:
> > > > Isn't it time to stop going to great effort to support Python
> > >
> > > If you live in a world where you get to decide that, sure.  Not
> > > everyone does.
> > >
> >
> > Everyone gets to decide how much time and effort they put into
> > supporting an old and unsupported system.
>
> Mostly not...  In the real world you typically are beholden to
> customers (be they internal or external), and you are beholden to your
> bosses (be they the same or different people from the first group).
> What you say is true only if you have no customers or bosses to whom
> you have obligations, or have sufficient financial freedom or
> influence to ignore them and are willing to accept the consequences.
>

Is your boss/client smart enough to understand the concept of putting
in effort now to pay off significant dividends later?

Does your boss/client recognize that using software that isn't getting
security patches means you're vulnerable?

Actually, does your boss/client even care what your chosen language
is? Certainly in the case of clients or customers, it's extremely
common for them to have expectations in terms of "make it work", not
"keep it running on Python 2".

So long as it's fairly easy to keep it going on Py2, sure, keep it
going on Py2. But if it's going to be a lot of effort - and,
increasingly, it will - then you need to be willing to take the
non-lazy option and do the migration, rather than perpetually putting
it off and incurring more and more technical debt in the process.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

On 2/11/20 4:05 AM, Chris Angelico wrote:
> Or just the recognition that, eventually, technical debt has to be
> paid. 

Speaking about technical debt is certainly fashionable these days.  As
if we've somehow discovered a brand new way of looking at things.  But
it doesn't matter what you do, there's always real cost, and therefore
always technical debt. Moving to Python 3 incurs technical debt.
Staying with Python 2 incurs technical debt.  Thus I wonder if the term
is actually that useful.

I know what you mean, though.  The cost of staying with Python2 is
increasing rapidly compared to the cost of porting to Python3.  Unlike
the nebulous term, "technical debt," the cost of staying with Python2 vs
porting to Python3 can be quantified in real dollar amounts.  I've no
doubt that the calculus is in favor of Python2 a while longer for many
people.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote:
> > > Isn't it time to stop going to great effort to support Python
> >
> > If you live in a world where you get to decide that, sure.  Not
> > everyone does.
> >
> 
> Everyone gets to decide how much time and effort they put into
> supporting an old and unsupported system.

Mostly not...  In the real world you typically are beholden to
customers (be they internal or external), and you are beholden to your
bosses (be they the same or different people from the first group).
What you say is true only if you have no customers or bosses to whom
you have obligations, or have sufficient financial freedom or
influence to ignore them and are willing to accept the consequences.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Wed, Feb 12, 2020 at 3:57 AM Python  wrote:
>
> On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote:
> > > > I've been using the timestamp() method:
> > >
> > > That's the key piece of info.  This does appear to work, though still
> > > not on python2.  That, as you say, is my problem.  But thankfully Jon
> > > Ribbens has the save:
> >
> > Isn't it time to stop going to great effort to support Python
>
> If you live in a world where you get to decide that, sure.  Not
> everyone does.
>

Everyone gets to decide how much time and effort they put into
supporting an old and unsupported system. Are you telling me that
someone is enslaving you and forcing you to continue supporting Python
2, or are you actually saying that it's less effort to keep
maintaining old code than to port to Py3? As I said in the previous
email, I did NOT say that it's time to instantly drop Py2 like a hot
potato. (And if you do nothing, a hot potato just becomes a cold
potato. Thank you, Bernard.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote:
> > > I've been using the timestamp() method:
> >
> > That's the key piece of info.  This does appear to work, though still
> > not on python2.  That, as you say, is my problem.  But thankfully Jon
> > Ribbens has the save:
> 
> Isn't it time to stop going to great effort to support Python 

If you live in a world where you get to decide that, sure.  Not
everyone does.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Jon Ribbens via Python-list]

On 2020-02-11, Chris Angelico  wrote:
> On Tue, Feb 11, 2020 at 10:01 PM Jon Ribbens via Python-list
> wrote:
>> So while it's been about 6 years since anyone should have been
>> starting any new projects using Python 2, there are plenty of
>> projects that are older than that and still need supporting,
>> and often it'd take some pretty huge unavoidable requirement
>> to motivate a port to Python 3.
>
> Or just the recognition that, eventually, technical debt has to be
> paid. I didn't say that everything has to stop supporting Py2
> instantly now that it's 2020, but that it's time to stop going to
> great lengths for it. Py2 is a legacy system and has been for a long
> time now, and if it takes a lot of effort to keep maintaining it, then
> it's time to consider porting to Py3. Just how much work are you going
> to do, to avoid the work of porting?

Not doing something generally doesn't involve any work. Occasionally
there's a very small amount of work when something that would have
been trivial in Python 3 is slightly harder in Python 2 - this thread
for example, where it appears to involve one extra line of code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Tue, Feb 11, 2020 at 10:01 PM Jon Ribbens via Python-list
 wrote:
>
> On 2020-02-11, Chris Angelico  wrote:
> >> That's the key piece of info.  This does appear to work, though still
> >> not on python2.  That, as you say, is my problem.  But thankfully Jon
> >> Ribbens has the save:
> >
> > Isn't it time to stop going to great effort to support Python 2?
>
> That depends on what existing systems people need to support. The main
> project I work on pre-dates the existence of Python's 'datetime'
> module, let alone Python 3. It still generally uses 1 and 0 for True
> and False because True and False didn't exist when we started.
>
> This project will never move to Python 3. It was a happy and momentous
> day, fairly recently, when we were able to move to Python 2.7 - albeit
> we're basically stuck on Python 2.7.5 (plus random patches from RedHat
> making it not-really-2.7.5).
>
> So while it's been about 6 years since anyone should have been
> starting any new projects using Python 2, there are plenty of
> projects that are older than that and still need supporting,
> and often it'd take some pretty huge unavoidable requirement
> to motivate a port to Python 3.

Or just the recognition that, eventually, technical debt has to be
paid. I didn't say that everything has to stop supporting Py2
instantly now that it's 2020, but that it's time to stop going to
great lengths for it. Py2 is a legacy system and has been for a long
time now, and if it takes a lot of effort to keep maintaining it, then
it's time to consider porting to Py3. Just how much work are you going
to do, to avoid the work of porting?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Jon Ribbens via Python-list]

On 2020-02-11, Chris Angelico  wrote:
>> That's the key piece of info.  This does appear to work, though still
>> not on python2.  That, as you say, is my problem.  But thankfully Jon
>> Ribbens has the save:
>
> Isn't it time to stop going to great effort to support Python 2?

That depends on what existing systems people need to support. The main
project I work on pre-dates the existence of Python's 'datetime'
module, let alone Python 3. It still generally uses 1 and 0 for True
and False because True and False didn't exist when we started.

This project will never move to Python 3. It was a happy and momentous
day, fairly recently, when we were able to move to Python 2.7 - albeit
we're basically stuck on Python 2.7.5 (plus random patches from RedHat
making it not-really-2.7.5).

So while it's been about 6 years since anyone should have been
starting any new projects using Python 2, there are plenty of
projects that are older than that and still need supporting,
and often it'd take some pretty huge unavoidable requirement
to motivate a port to Python 3.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Tue, Feb 11, 2020 at 12:31 PM Python  wrote:
>
> On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> > [...] instead of using the undocumented and unsupported strftime %s
> > format code
>
> I'm not sure this characterization is accurate... the docs (for both
> Python 2 and 3) say:
>
> The full set of format codes supported varies across platforms,
> because Python calls the platform C library’s strftime() function,
> and platform variations are common. To see the full set of format
> codes supported on your platform, consult the strftime(3)
> documentation.
>
> And %s is surely there... so it is both documented and supported by
> virtue of Python's docs saying that whatever your OS supports is
> supported.  But this is largely beside the point.

https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes

The C standard mandates a particular set of format codes, quoted in
that page, and %s is not one of them. Also, Python has its own test
suite and it ensures certain behaviours of datetime.strftime, and %s
is not tested there. So from Python's point of view, I stand by the
description of %s as being undocumented and unsupported. It might
happen to work, but if you link Python against a different C standard
library, it could change that behaviour even on the same computer.

> > I've been using the timestamp() method:
>
> That's the key piece of info.  This does appear to work, though still
> not on python2.  That, as you say, is my problem.  But thankfully Jon
> Ribbens has the save:

Isn't it time to stop going to great effort to support Python 2?

> On Tue, Feb 11, 2020 at 12:59:04AM -, Jon Ribbens via Python-list wrote:
> > On 2020-02-10, Python  wrote:
> > > So far, so good.  However, when you go to use this object, the time it
> > > represents is in fact wrong.
> >
> > Unsurprisingly for a language feature that's been around for nearly
> > 17 years, no it isn't.
>
> Well, fine, but it is at best not documented as clearly as it could be
> (in the man pages of my system, which is not Python's fault).  But
> you've given me what I need to solve my problem:
>
> >  print dt.strftime("%s")
> > > 1580452245
> >
> > That's asking your libc's strftime to process the time through the
> > "%s" format code [...] If you're using GNU libc however then it uses the 
> > time
> > information given and the timezone from the 'TZ' environment variable
> > and returns seconds since the Unix epoch:
>
> And knowing this, I can get what I need, on Python2 and python3, by
> doing what I was already doing, but setting os.environ["TZ"] = "GMT"
> in the code itself.  Sure it's a bit hacky, but it won't matter here,
> and it gets the right answer, which does matter.
>

Yes, it's very hacky. The sort of hack that deserves a comment with a
TODO in it. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> [...] instead of using the undocumented and unsupported strftime %s
> format code

I'm not sure this characterization is accurate... the docs (for both
Python 2 and 3) say:

The full set of format codes supported varies across platforms,
because Python calls the platform C library’s strftime() function,
and platform variations are common. To see the full set of format
codes supported on your platform, consult the strftime(3)
documentation.

And %s is surely there... so it is both documented and supported by
virtue of Python's docs saying that whatever your OS supports is
supported.  But this is largely beside the point.

> I've been using the timestamp() method:

That's the key piece of info.  This does appear to work, though still
not on python2.  That, as you say, is my problem.  But thankfully Jon
Ribbens has the save:


On Tue, Feb 11, 2020 at 12:59:04AM -, Jon Ribbens via Python-list wrote:
> On 2020-02-10, Python  wrote:
> > So far, so good.  However, when you go to use this object, the time it
> > represents is in fact wrong.
> 
> Unsurprisingly for a language feature that's been around for nearly
> 17 years, no it isn't.

Well, fine, but it is at best not documented as clearly as it could be
(in the man pages of my system, which is not Python's fault).  But
you've given me what I need to solve my problem:

>  print dt.strftime("%s")
> > 1580452245
> 
> That's asking your libc's strftime to process the time through the
> "%s" format code [...] If you're using GNU libc however then it uses the time
> information given and the timezone from the 'TZ' environment variable
> and returns seconds since the Unix epoch:

And knowing this, I can get what I need, on Python2 and python3, by
doing what I was already doing, but setting os.environ["TZ"] = "GMT"
in the code itself.  Sure it's a bit hacky, but it won't matter here,
and it gets the right answer, which does matter.

Thanks

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Jon Ribbens via Python-list]

On 2020-02-10, Python  wrote:
> So far, so good.  However, when you go to use this object, the time it
> represents is in fact wrong.

Unsurprisingly for a language feature that's been around for nearly
17 years, no it isn't.

> For example:
>
 print dt.strftime("%s")
> 1580452245

That's asking your libc's strftime to process the time through the
"%s" format code, which has no defined behaviour under either Python
or POSIX. If you're using GNU libc however then it uses the time
information given and the timezone from the 'TZ' environment variable
and returns seconds since the Unix epoch:

>>> dt.strftime('%s')
'1580452245'
>>> import os
>>> os.environ['TZ'] = 'UTC'
>>> dt.strftime('%s')
'1580434245'

If you need to know the seconds since the epoch then in Python 3.3+
you can do that with dt.timestamp(). In Python 2.7 you can use the UTC
class you created:

(dt - datetime(1970, 1, 1, 0, 0, 0, 0, GMT())).total_seconds()

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Tue, Feb 11, 2020 at 11:17 AM Python  wrote:
>
> On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> > On Tue, Feb 11, 2020 at 10:42 AM Python  wrote:
> > > Now, you can instantiate a datetime.datetime object with the times you
> > > want, and pass an instance of this class as the tzinfo argument to the
> > > constructor.  Also no problem:
> >
> > Rather than try to create your own GMT() object, have you considered
> > using datetime.timezone.utc ? I tested it in your examples and it
> > works just fine.
>
> Not here it doesn't:
>
> >>> import datetime
> >>> dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, 
> >>> datetime.timezone.utc)
> >>> print(dt)
> 2020-01-31 01:30:45.987654+00:00
> >>> print(dt.strftime("%s"))
> 1580452245
>
> That's the same erroneous result from my example.  The correct value
> is again 1580434245.  Unless you've done something subtlely
> different...

I haven't verified the arithmetic or that the date command is actually
giving the result you want/expect here, but in my testing, I got what
looked like correct results. However, instead of using the
undocumented and unsupported strftime %s format code, I've been using
the timestamp() method:

https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp

rosuav@sikorsky:~$ cat utctest.py
import datetime
dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, datetime.timezone.utc)
print(dt)
print(dt.timestamp())
rosuav@sikorsky:~$ python3.9 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.8 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.7 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.6 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.5 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654
rosuav@sikorsky:~$ python3.4 utctest.py
2020-01-31 01:30:45.987654+00:00
1580434245.987654

My interpretation is that, on your platform, strftime("%s") is broken
in the presence of tzinfo.

> Also it's only available on Python3, which may not be the end of the
> world, but the tool I'm working on is--for the moment at
> least--expected to work on both python2.7 and 3.  But it's irrelevant
> if it doesn't give the correct result, which seems to still be the
> case.
>

That may be your problem, but it's not mine, and I'm not going to
attempt to answer for Python 2.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> On Tue, Feb 11, 2020 at 10:42 AM Python  wrote:
> > Now, you can instantiate a datetime.datetime object with the times you
> > want, and pass an instance of this class as the tzinfo argument to the
> > constructor.  Also no problem:
> 
> Rather than try to create your own GMT() object, have you considered
> using datetime.timezone.utc ? I tested it in your examples and it
> works just fine.

Not here it doesn't:

>>> import datetime
>>> dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, 
>>> datetime.timezone.utc)
>>> print(dt)
2020-01-31 01:30:45.987654+00:00
>>> print(dt.strftime("%s"))
1580452245

That's the same erroneous result from my example.  The correct value
is again 1580434245.  Unless you've done something subtlely
different...

Also it's only available on Python3, which may not be the end of the
world, but the tool I'm working on is--for the moment at
least--expected to work on both python2.7 and 3.  But it's irrelevant
if it doesn't give the correct result, which seems to still be the
case.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

On Tue, Feb 11, 2020 at 10:42 AM Python  wrote:
>
> As best I can tell, Python has no means to make use of the system's
> timezone info.  In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the timezone you care about.  In the general
> case, this is hard, but since the timezone my dates are in is always
> GMT, it's no problem:
>
> class GMT(datetime.tzinfo):
> def utcoffset(self, dt):
> return datetime.timedelta(hours=0)
> def dst(self, dt):
> return datetime.timedelta(minutes=0)
> def tzname(self, dt):
> return "GMT"
>
> Now, you can instantiate a datetime.datetime object with the times you
> want, and pass an instance of this class as the tzinfo argument to the
> constructor.  Also no problem:

Rather than try to create your own GMT() object, have you considered
using datetime.timezone.utc ? I tested it in your examples and it
works just fine.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

On Mon, Feb 10, 2020 at 05:52:59PM -0600, Skip Montanaro wrote:
> > As best I can tell, Python has no means to make use of the system's
> > timezone info.  In order to make datetime "timezone aware", you need
> > to manually create a subclass of datetime.tzinfo, whose methods return
> > the correct values for the timezone you care about.
> >
>  ...
> 
> > Does Python have an alternative way to do the above, with correct
> > results?
> >
> 
> The datetime module's manipulation of timezones is pretty low-level. Maybe
> try arrow?
> 
> https://arrow.readthedocs.io/en/latest/

Yeah, this looks like exacly what I'm looking for, but I need
something that's part of the standard Python distribution, due to
constraints I have no control over.  [This is perhaps not strictly
true, but for all intents and purposes...] 

FWIW, manipulating dates on POSIX systems is pretty much a nightmare,
so it's hard to blame Python entirely for the state of things.

Thanks though.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Skip Montanaro]

> As best I can tell, Python has no means to make use of the system's
> timezone info.  In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the timezone you care about.
>
 ...

> Does Python have an alternative way to do the above, with correct
> results?
>

The datetime module's manipulation of timezones is pretty low-level. Maybe
try arrow?

https://arrow.readthedocs.io/en/latest/

Skip

>
-- 
https://mail.python.org/mailman/listinfo/python-list

datetime seems to be broken WRT timezones (even when you add them)

[Python]

As best I can tell, Python has no means to make use of the system's
timezone info.  In order to make datetime "timezone aware", you need
to manually create a subclass of datetime.tzinfo, whose methods return
the correct values for the timezone you care about.  In the general
case, this is hard, but since the timezone my dates are in is always
GMT, it's no problem:

class GMT(datetime.tzinfo):
def utcoffset(self, dt):
return datetime.timedelta(hours=0)
def dst(self, dt):
return datetime.timedelta(minutes=0)
def tzname(self, dt):
return "GMT"

Now, you can instantiate a datetime.datetime object with the times you
want, and pass an instance of this class as the tzinfo argument to the
constructor.  Also no problem:

>>> dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, GMT())
>>> dt
datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, tzinfo=<__main__.GMT object 
at 0x7f9084e2add0>)
>>> print dt
2020-01-31 01:30:45.987654+00:00

Note the tzinfo object, and the +00:00 indicating this is indeed in
GMT.  If you create a "naive" datetime object, you don't get that:

>>> xy = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
>>> xy
datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
>>> print xy
2020-01-31 01:30:45.987654


So far, so good.  However, when you go to use this object, the time it
represents is in fact wrong.  For example:

>>> print dt.strftime("%s")
1580452245

Using the date command, we can easily see that it is incorrect:

# Ask for UTC, gives the wrong time
$ date -u -d "@1580452245"
Fri Jan 31 06:30:45 UTC 2020

# Ask for local time, gives the time I specified... which should have
# been in GMT, but is in my local timezone
$ date -d "@1580452245"
Fri Jan 31 01:30:45 EST 2020

And the correct value should have been:
$ date -d "2020-01-31 1:30:45 GMT" +%s
1580434245

Same results under Python2.7 or Python3.

:( :( :(

I suspect this is because the underlying implementation uses
strftime() which takes struct tm, which has no field to contain the
timezone info, and does not do the necessary conversion before handing
it off.  I'm not sure what the date command is doing differently, but
it clearly is able to get the correct answer.

Does Python have an alternative way to do the above, with correct
results?

Thanks

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: timezones

[Jaap van Wingerde]

The blog of Paul Gansele [1] made me trying an other approach.

#!/usr/bin/env python3
# -*- coding: utf_8 -*-
### tested with python3.5
from datetime import datetime, timedelta, timezone
from dateutil import tz
amsterdam = tz.gettz('Europe/Amsterdam')
utc = tz.gettz('utc')
amsterdam_datetime = datetime(2018, 12, 17, 11, 31, 26,
tzinfo=amsterdam) print(amsterdam_datetime)
tuple = amsterdam_datetime.utctimetuple()
utc_datetime = datetime(tuple[0], tuple[1], tuple[2], tuple[3],
tuple[4], tuple[5]) print(utc_datetime)
amsterdam_datetime = datetime(2018, 6, 17, 11, 31, 26, tzinfo=amsterdam)
print(amsterdam_datetime)
tuple = amsterdam_datetime.utctimetuple()
utc_datetime = datetime(tuple[0], tuple[1], tuple[2], tuple[3],
tuple[4], tuple[5]) print(utc_datetime)

Output:
2018-12-17 11:31:26+01:00
2018-12-17 10:31:26
2018-06-17 11:31:26+02:00
2018-06-17 09:31:26

[1]
pytz: The Fastest Footgun in the West
2018-03-19
https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html


Op 2019-02-07T17:56:21+ schreef David Raymond
 in bericht
,
inzake:  het volgende.

> I'd say if the documentation mentions it, but doesn't say why, then
> we're not gonna be able to do much better for you as far as "why"
> goes.
> 
> http://pytz.sourceforge.net/
> 
> "Unfortunately using the tzinfo argument of the standard datetime
> constructors "does not work" with pytz for many timezones."
> 
> But it looks like they suggest something along the lines of...
> 
> timezone('Europe/Amsterdam').localize(datetime(2018, 12, 17, 11, 31,
> 26))
> 
> 
> From the examples on
> http://pytz.sourceforge.net/#problems-with-localtime ...
> 
> >>> eastern = timezone('US/Eastern')
> >>> fmt = '%Y-%m-%d %H:%M:%S %Z%z'
> >>> loc_dt = datetime(2002, 10, 27, 1, 30, 00)
> >>> est_dt = eastern.localize(loc_dt, is_dst=True)
> >>> edt_dt = eastern.localize(loc_dt, is_dst=False)
> >>> print(est_dt.strftime(fmt) + ' / ' + edt_dt.strftime(fmt))  
> 2002-10-27 01:30:00 EDT-0400 / 2002-10-27 01:30:00 EST-0500
> 
> 
> Browse through their examples and see if you can find something
> similar that works for you.
> 
> 
> -Original Message-
> From: Python-list
> [mailto:python-list-bounces+david.raymond=tomtom@python.org] On
> Behalf Of Jaap van Wingerde Sent: Wednesday, February 06, 2019 9:27
> AM To: python-list@python.org Subject: timezones
> 
> I made a small script to practise with timezones:
> 
> #!/usr/bin/env python3
> # -*- coding: utf_8 -*-
> from datetime import datetime, timedelta
> from pytz import timezone
> import pytz
> amsterdam_datetime = datetime(2018, 12, 17, 11, 31, 26,
> tzinfo=timezone('Europe/Amsterdam'))
> print(amsterdam_datetime)
> utc_datetime = amsterdam_datetime.astimezone(pytz.utc)
> print(utc_datetime)
> amsterdam_datetime = datetime(2018, 6, 17, 11, 31, 26,
> tzinfo=timezone('Europe/Amsterdam'))
> print(amsterdam_datetime)
> utc_datetime = amsterdam_datetime.astimezone(pytz.utc)
> print(utc_datetime)
> 
> The output of the script is:
> 2018-12-17 11:31:26+00:20
> 2018-12-17 11:11:26+00:00
> 2018-06-17 11:31:26+00:20
> 2018-06-17 11:11:26+00:00
> 
> I respected:
> 2018-12-17 11:31:26+01:00
> 2018-12-17 10:31:26+00:00
> 2018-06-17 11:31:26+02:00
> 2018-06-17 09:31:26+00:00
> 
> I need this functionality for adjusting wrong timestamps in Android
> JPG-images as the 'Exif.GPSInfo.GPSTimeStamp' and
> 'Exif.GPSInfo.GPSDateStamp' are missing.
> 
> Why I get this unrespected results?
> 
> Kind regards,
> Jaap.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: timezones

[David Raymond]

I'd say if the documentation mentions it, but doesn't say why, then we're not 
gonna be able to do much better for you as far as "why" goes.

http://pytz.sourceforge.net/

"Unfortunately using the tzinfo argument of the standard datetime constructors 
"does not work" with pytz for many timezones."

But it looks like they suggest something along the lines of...

timezone('Europe/Amsterdam').localize(datetime(2018, 12, 17, 11, 31, 26))


>From the examples on http://pytz.sourceforge.net/#problems-with-localtime ...

>>> eastern = timezone('US/Eastern')
>>> fmt = '%Y-%m-%d %H:%M:%S %Z%z'
>>> loc_dt = datetime(2002, 10, 27, 1, 30, 00)
>>> est_dt = eastern.localize(loc_dt, is_dst=True)
>>> edt_dt = eastern.localize(loc_dt, is_dst=False)
>>> print(est_dt.strftime(fmt) + ' / ' + edt_dt.strftime(fmt))
2002-10-27 01:30:00 EDT-0400 / 2002-10-27 01:30:00 EST-0500


Browse through their examples and see if you can find something similar that 
works for you.


-Original Message-
From: Python-list 
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
Jaap van Wingerde
Sent: Wednesday, February 06, 2019 9:27 AM
To: python-list@python.org
Subject: timezones

I made a small script to practise with timezones:

#!/usr/bin/env python3
# -*- coding: utf_8 -*-
from datetime import datetime, timedelta
from pytz import timezone
import pytz
amsterdam_datetime = datetime(2018, 12, 17, 11, 31, 26,
tzinfo=timezone('Europe/Amsterdam'))
print(amsterdam_datetime)
utc_datetime = amsterdam_datetime.astimezone(pytz.utc)
print(utc_datetime)
amsterdam_datetime = datetime(2018, 6, 17, 11, 31, 26,
tzinfo=timezone('Europe/Amsterdam'))
print(amsterdam_datetime)
utc_datetime = amsterdam_datetime.astimezone(pytz.utc)
print(utc_datetime)

The output of the script is:
2018-12-17 11:31:26+00:20
2018-12-17 11:11:26+00:00
2018-06-17 11:31:26+00:20
2018-06-17 11:11:26+00:00

I respected:
2018-12-17 11:31:26+01:00
2018-12-17 10:31:26+00:00
2018-06-17 11:31:26+02:00
2018-06-17 09:31:26+00:00

I need this functionality for adjusting wrong timestamps in Android
JPG-images as the 'Exif.GPSInfo.GPSTimeStamp' and
'Exif.GPSInfo.GPSDateStamp' are missing.

Why I get this unrespected results?

Kind regards,
Jaap.


-- 

Jaap van Wingerde
e-mail: 1234567...@vanwingerde.nl

-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

timezones

[Jaap van Wingerde]

I made a small script to practise with timezones:

#!/usr/bin/env python3
# -*- coding: utf_8 -*-
from datetime import datetime, timedelta
from pytz import timezone
import pytz
amsterdam_datetime = datetime(2018, 12, 17, 11, 31, 26,
tzinfo=timezone('Europe/Amsterdam'))
print(amsterdam_datetime)
utc_datetime = amsterdam_datetime.astimezone(pytz.utc)
print(utc_datetime)
amsterdam_datetime = datetime(2018, 6, 17, 11, 31, 26,
tzinfo=timezone('Europe/Amsterdam'))
print(amsterdam_datetime)
utc_datetime = amsterdam_datetime.astimezone(pytz.utc)
print(utc_datetime)

The output of the script is:
2018-12-17 11:31:26+00:20
2018-12-17 11:11:26+00:00
2018-06-17 11:31:26+00:20
2018-06-17 11:11:26+00:00

I respected:
2018-12-17 11:31:26+01:00
2018-12-17 10:31:26+00:00
2018-06-17 11:31:26+02:00
2018-06-17 09:31:26+00:00

I need this functionality for adjusting wrong timestamps in Android
JPG-images as the 'Exif.GPSInfo.GPSTimeStamp' and
'Exif.GPSInfo.GPSDateStamp' are missing.

Why I get this unrespected results?

Kind regards,
Jaap.


-- 

Jaap van Wingerde
e-mail: 1234567...@vanwingerde.nl

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29885] Allow GMT timezones to be used in datetime.

[Decorater]

Change by Decorater :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29885] Allow GMT timezones to be used in datetime.

[Martin Panter]

Martin Panter added the comment:

Does the “astimezone” method work for you? 


>>> from datetime import *
>>> aedt = timezone(+timedelta(hours=11))
>>> local = datetime.now(aedt)
>>> format(local)
'2017-03-23 19:14:41.410334+11:00'
>>> gmt = local.astimezone(timezone.utc)
>>> format(gmt)
'2017-03-23 08:14:41.410334+00:00'

--
nosy: +martin.panter
resolution:  -> works for me

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29885] Allow GMT timezones to be used in datetime.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Use pytz (https://pypi.python.org/pypi/pytz).

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29885] Allow GMT timezones to be used in datetime.

[Decorater]

New submission from Decorater:

I noticed that there is no ways to convert local times to GMT if I realize that 
some other object (sometimes from a server) is using GMT and they happen to be 
ahead of my current time. As such it would be great if one can convert their 
current time that can be in an datetime object to an GMT time to see how much 
time has passed since something happened on their zone if so desired (otherwise 
can cause undesired or undefined consequences).

--
components: Library (Lib)
messages: 290027
nosy: Decorater
priority: normal
severity: normal
status: open
title: Allow GMT timezones to be used in datetime.
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29885>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: pytz and Python timezones

[Carl Meyer]

Hi Johannes,

On 06/11/2016 05:37 AM, Johannes Bauer wrote:
> I try to create a localized timestamp
> in the easiest possible way. So, intuitively, I did this:
> 
> datetime.datetime(2016,1,1,0,0,0,tzinfo=pytz.timezone("Europe/Berlin"))

That is indeed intuitive, but unfortunately (due to a misunderstanding
between the original authors of Python's datetime module and the author
of pytz about how timezone-aware datetimes should work in Python) it is
not correct. The correct way to create a localized datetime using pytz
is this:

tz = pytz.timezone('Europe/Berlin')
dt = tz.localize(datetime.datetime(2016, 1, 1, 0, 0, 0)

This is documented prominently in the pytz documentation:
http://pytz.sourceforge.net/

> Which gives me:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= LMT+0:53:00 STD>)
> 
> Uh... what?

When you create a pytz timezone object, it encompasses all historical
UTC offsets that have ever been in effect in that location. When you
pass a datetime to the `localize()` method of that timezone object, it
is able to figure out which actual UTC offset was in effect at that
local time in that location, and apply the correct "version" of itself
to that datetime.

However, no such logic is built into the datetime module itself. So when
you just apply a pytz timezone directly to the tzinfo property of a
datetime, pytz by default falls back to the first entry in its
historical table of UTC offsets for that location. For most locations,
that is something called "LMT" or Local Mean Time, which is the
customary time in use at that location prior to the standardization of
timezones. And in most locations, LMT is offset from UTC by a strange
number of minutes. That's why you see "LMT" and the odd 53-minute offset
above.

> This here:
> 
> pytz.timezone("Europe/Berlin").localize(datetime.datetime(2016,1,1))
> 
> Gives me the expected result of:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= CET+1:00:00 STD>)
> 
> Can someone explain what's going on here and why I end up with the weird
> "00:53" timezone? Is this a bug or am I doing things wrong?

It is not a bug in pytz or in datetime, in that it is intended behavior,
although that behavior is unfortunately obscure, bug-prone, and
little-understood.

If you are masochistic enough to want to understand how this bad
situation came to be, and what might be done about it, you can read
through PEPs 431 and 495.

Carl



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pytz and Python timezones

[Lawrence D’Oliveiro]

On Saturday, June 11, 2016 at 11:37:38 PM UTC+12, Johannes Bauer wrote:
> I try to create a localized timestamp in the easiest possible way.

Localized timestamps are perhaps not as easy as you think.

> So, intuitively, I did this:
> 
> datetime.datetime(2016,1,1,0,0,0,tzinfo=pytz.timezone("Europe/Berlin"))
> 
> Which gives me:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= LMT+0:53:00 STD>)
> 
> Uh... what?

A careful reading of 
 indicates 
that those classes expect their attributes to already be in local time. I don’t 
think they have the smarts to examine the tzinfo you pass them and decide which 
of possibly several sections of historical information might apply to them. So 
you ended up with it being interpreted according to the oldest section of the 
“Europe/Berlin” timezone data (the one up to April 1893).

Anyway, that’s my guess.

> This here:
> 
> pytz.timezone("Europe/Berlin").localize(datetime.datetime(2016,1,1))
> 
> Gives me the expected result of:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= CET+1:00:00 STD>)

Clearly pytz has much more smarts about handling local times.

My general rule about dates/times is: always work in UTC. Convert to local 
dates/times only for display purposes.
-- 
https://mail.python.org/mailman/listinfo/python-list

pytz and Python timezones

[Johannes Bauer]

Hi there,

first off, let me admit that I have a hard time comprehensively wrapping
my head around timezones. Everything around them is much more
complicated than it seems, IMO. That said, I'm trying to do things the
"right" way and stumbled upon some weird issue which I can't explain.
I'm unsure what is happening here. I try to create a localized timestamp
in the easiest possible way. So, intuitively, I did this:

datetime.datetime(2016,1,1,0,0,0,tzinfo=pytz.timezone("Europe/Berlin"))

Which gives me:

datetime.datetime(2016, 1, 1, 0, 0, tzinfo=)

Uh... what?

This here:

pytz.timezone("Europe/Berlin").localize(datetime.datetime(2016,1,1))

Gives me the expected result of:

datetime.datetime(2016, 1, 1, 0, 0, tzinfo=)

Can someone explain what's going on here and why I end up with the weird
"00:53" timezone? Is this a bug or am I doing things wrong?

Thanks,
Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pytz and Python timezones

[Irmen de Jong]

On 11-6-2016 13:37, Johannes Bauer wrote:
> Hi there,
> 
> first off, let me admit that I have a hard time comprehensively wrapping
> my head around timezones. Everything around them is much more
> complicated than it seems, IMO.

They might not seem complicated, but actually they are. Mindbogglingly so:
https://www.youtube.com/watch?v=-5wpm-gesOY

> pytz.timezone("Europe/Berlin").localize(datetime.datetime(2016,1,1))
> 
> Gives me the expected result of:
> 
> datetime.datetime(2016, 1, 1, 0, 0, tzinfo= CET+1:00:00 STD>)
> 
> Can someone explain what's going on here and why I end up with the weird
> "00:53" timezone? Is this a bug or am I doing things wrong?

I ran into the same issue a while ago and have since accepted that "the right 
way to do
it" is indeed not passing a tzinfo into the datetime constructor, but to always 
use the
second form with tz.localize(datetime).
I suppose it is a problem (not so much a bug) caused by the way timezones are 
done
internally in pytz and/or datetime but haven't looked into the details. Mostly 
because
of what is said the video I linked above :)

Irmen

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue19065] sqlite3 timestamp adapter chokes on timezones

[Berker Peksag]

Berker Peksag added the comment:

> Do you know what would be the correct step to propose a deprecation in the 
> sqlite3 module of Python proper?

I've opened issue 26651 (patch included) to deprecate them.

--
nosy: +berker.peksag
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed
type: crash -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Missing something about timezones

[Peter Pearson]

On Mon, 14 Mar 2016 10:19:23 -0500, Skip Montanaro wrote:
> Is this correct (today, with Daylight Savings in effect)?
>
>>>> import pytz
>>>> i.timezone
> 'America/Chicago'
>>>> pytz.timezone(i.timezone)
>
>>>> ot
> datetime.datetime(2016, 3, 14, 9, 30, tzinfo= 'America/New_York' EDT-1 day, 20:00:00 DST>)
>>>> ot.tzinfo
>


I've stubbed my toe many times on timezones and DST.  Here are
some notes I've accumulated:

 * datetime.datetime(..., tzinfo=tz) doesn't work right for timezones
   that involve daylight-saving time, but nobody gets around to fixing
   it because it's written in C; and

 * knowing this, the creators of pytz thoughtfully furnished a
   workaround, in the form of the "localize" method of a pytz.timezone
   object:

>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0)) 
>>> print(loc_dt.strftime(fmt))
2002-10-27 06:00:00 EST-0500


$ cat temp2.py
from datetime import datetime
from pytz import timezone

print(str(datetime(2015, 1, 31, 12, tzinfo=timezone("US/Pacific"
print(str(datetime(2015, 7, 31, 12, tzinfo=timezone("US/Pacific"

print(str(timezone("US/Pacific").localize(datetime(2015, 1, 31, 12
print(str(timezone("US/Pacific").localize(datetime(2015, 7, 31, 12

$ python temp2.py
2015-01-31 12:00:00-08:00
2015-07-31 12:00:00-08:00 <- wrong
2015-01-31 12:00:00-08:00
2015-07-31 12:00:00-07:00 <- right
$

Good luck!

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Missing something about timezones

[Carl Meyer]

Hi Skip,

On 03/14/2016 09:32 AM, Skip Montanaro wrote:
> On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly  wrote:
>> Why should it? You only asked pytz for the Chicago timezone. You
>> didn't ask for it relative to any specific time.
> 
> Thanks. I thought using America/Chicago was supposed to automagically
> take into account transitions into and out of Daylight Savings. Is
> there some way to get that?

Yes, pytz can handle DST correctly automatically when you give it
'America/Chicago', but until you apply that timezone to a particular
datetime, there is no DST to handle. There is no implicit assumption of
"today" when you do `pytz.timezone('America/Chicago').

If you apply the timezone to a particular datetime, you'll see that it
does reflect DST correctly:

>>> import datetime, pytz
>>> tz = pytz.timezone('America/Chicago')
>>> tz

>>> import datetime
>>> dt = datetime.datetime.now()
>>> dtl = tz.localize(dt)
>>> dtl
datetime.datetime(2016, 3, 14, 10, 11, 13, 514375, tzinfo=)

Carl



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Missing something about timezones

[Skip Montanaro]

On Mon, Mar 14, 2016 at 11:20 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> Note that the above example is technically incorrect since
> datetime.now() returns local time and I'm not in the Chicago timezone,
> but it demonstrates the process.
>
> Also, if you haven't already read the pytz documentation, you should.
> http://pythonhosted.org/pytz/

Thanks. I have remained pretty naive about timezones (sorry for the
pun). The platform I use actually does the right thing, but like a
dope I failed to use the mechanisms it provided.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Missing something about timezones

[Ian Kelly]

On Mon, Mar 14, 2016 at 9:32 AM, Skip Montanaro
 wrote:
> On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly  wrote:
>> Why should it? You only asked pytz for the Chicago timezone. You
>> didn't ask for it relative to any specific time.
>
> Thanks. I thought using America/Chicago was supposed to automagically
> take into account transitions into and out of Daylight Savings. Is
> there some way to get that?

Use the timezone to localize a specific time, and then if it's
specifically the timezone that you're interested in, you can get it
from the datetime.

>>> from datetime import datetime
>>> import pytz
>>> tz = pytz.timezone('America/Chicago')
>>> tz

>>> dt = datetime.now()
>>> dt
datetime.datetime(2016, 3, 14, 10, 16, 40, 404608)
>>> loc_dt = tz.localize(dt)
>>> loc_dt
datetime.datetime(2016, 3, 14, 10, 16, 40, 404608, tzinfo=)

Note that the above example is technically incorrect since
datetime.now() returns local time and I'm not in the Chicago timezone,
but it demonstrates the process.

Also, if you haven't already read the pytz documentation, you should.
http://pythonhosted.org/pytz/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Missing something about timezones

[Skip Montanaro]

On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly  wrote:
> Why should it? You only asked pytz for the Chicago timezone. You
> didn't ask for it relative to any specific time.

Thanks. I thought using America/Chicago was supposed to automagically
take into account transitions into and out of Daylight Savings. Is
there some way to get that?

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Missing something about timezones

[Ian Kelly]

On Mon, Mar 14, 2016 at 9:19 AM, Skip Montanaro
 wrote:
> Is this correct (today, with Daylight Savings in effect)?
>
 import pytz
 i.timezone
> 'America/Chicago'
 pytz.timezone(i.timezone)
> 
 ot
> datetime.datetime(2016, 3, 14, 9, 30, tzinfo= 'America/New_York' EDT-1 day, 20:00:00 DST>)
 ot.tzinfo
> 
>
> Shouldn't the America/Chicago timezone reflect DST?

Why should it? You only asked pytz for the Chicago timezone. You
didn't ask for it relative to any specific time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Missing something about timezones

[Skip Montanaro]

Is this correct (today, with Daylight Savings in effect)?

>>> import pytz
>>> i.timezone
'America/Chicago'
>>> pytz.timezone(i.timezone)

>>> ot
datetime.datetime(2016, 3, 14, 9, 30, tzinfo=)
>>> ot.tzinfo


Shouldn't the America/Chicago timezone reflect DST?

Thx,

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue25963] strptime not parsing some timezones

[R. David Murray]

R. David Murray added the comment:

The code is shared by the two modules (it's in _strptime.py).  So, yes.

There is clearly a doc bug here (%Z needs a footnote in the table in the 
datetime docs), but there is no practical way to implement the parsing of 
arbitrary (non-locale) timezone strings, since it is not a one-to-one mapping.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, r.david.murray
versions: +Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25963] strptime not parsing some timezones

[Utkonos]

New submission from Utkonos:

I get a ValueError when running the following through strptime:

datetime.datetime.strptime('(CST)', '(%Z)')

But the following works:
datetime.datetime.strptime('(EST)', '(%Z)')

PST and MST also trigger the same exception.

--
messages: 257108
nosy: belopolsky, brett.cannon, utkonos
priority: normal
severity: normal
status: open
title: strptime not parsing some timezones
type: behavior
versions: Python 3.5

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25963>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19065] sqlite3 timestamp adapter chokes on timezones

[R. David Murray]

R. David Murray added the comment:

Just open an issue to propose the deprecation, if they aren't part of the 
DBAPI.  We wouldn't actually remove them, though, until after 2.7 goes out of 
maintenance (if then...we still haven't quite decided what we're going to do 
about removals post 2.7).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25428] Have `datetime` understand integer arguments for timezones

[leewz]

leewz added the comment:

Thanks. Will visit them.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25428] Have `datetime` understand integer arguments for timezones

[leewz]

New submission from leewz:

Current: If I want to create a datetime object with a particular timezone 
offset, I have to do this:

import datetime
mytime = datetime.datetime(2015, 10, 16, 9, 13, 0, 
tzinfo=datetime.timezone(datetime.timedelta(hours=-7)))

Or with imports:

from datetime import datetime, timezone, timedelta
mytime = datetime(2015, 10, 16, 9, 13, 0, 
tzinfo=timezone(timedelta(hours=-7)))

That's two extra imports and two extra objects created.


Requested way:
mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=-7)
# mytime.tzinfo == -7

Or if someone doesn't like the `tzinfo` keyword:
mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7)
# mytime.tzinfo == timezone(timedelta(-7))


For timezones, hours are the normal unit of time. At least, I think about time 
zones in hours, and I don't know who would think about them in minutes. There 
are half-hour offsets, so floats make sense to have.

Imagine you have about a year of experience dabbling in Python, and you're 
trying to do a relatively simple task, like reading PDT times and converting 
them to local time. You would go to the datetime docs, see that you need to 
pass in a tzinfo object. You look that up, and run into this:
"""tzinfo is an abstract base class, meaning that this class should not be 
instantiated directly. You need to derive a concrete subclass, and (at least) 
supply implementations of the standard tzinfo methods needed by the datetime 
methods you use."""

Well, great. If you want to convert times, you'll have to subclass an abstract 
base class, and implement five methods. You'd probably have to read the whole 
docs for this class, too. (The docs for tzinfo take nine Page Downs for me to 
scroll past.)

If you're not frightened off by the first two sentences, you'll see that 
there's the concrete subclass `datetime.timezone`. We're two levels down, now. 
Going there, you'll see that you need to pass in a timedelta object. Three 
levels. You need to learn about three classes just to specify an hour offset.

Timezones are something that many non-programmers understand, and the rules are 
pretty simple (barring DST, but the library doesn't really deal with it 
anyway). Ideally, it should be simple to do simple things.


PS: There seems to be unnecessary inconsistency with `.astimezone`, 
`fromtimestamp`, and `now` taking a `tz` kwarg rather than a `tzinfo` kwarg.

--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 253111
nosy: docs@python, leewz
priority: normal
severity: normal
status: open
title: Have `datetime` understand integer arguments for timezones
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25428>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25428] Have `datetime` understand integer arguments for timezones

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +belopolsky, lemburg
versions:  -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25428] Have `datetime` understand integer arguments for timezones

[R. David Murray]

R. David Murray added the comment:

timezone is relatively new.  Work is in progress to add better timezone support 
to datetime, but it is a complicated subject and may or may not make it into 
3.6.  In any case I think it is too soon to talk about this kind of API change, 
before the other work gets farther along.  That's probably also true for 
changes to the docs, although a concrete proposal there might have some chance.

There's a mailing list for talking specifically about datetime issues, you 
might want to post there (see mail.python.org, datetime-sig).

--
nosy: +r.david.murray
resolution:  -> later
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13466] new timezones

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Since nobody responded, I am closing this issue.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13466] new timezones

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Since Russia has fixed this bug legislatively last year, can we close the issue 
now?

http://www.theguardian.com/world/2014/jul/01/russia-state-duma-daylight-saving-time-summer

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13466
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19065] sqlite3 timestamp adapter chokes on timezones

[Gerhard Häring]

Gerhard Häring added the comment:

I'm -1 because I believe that ultimately, adapters and converters were a 
mistake to add to pysqlite. That's why I deprecated them in pysqlite 2.8.0.

Do you know what would be the correct step to propose a deprecation in the 
sqlite3 module of Python proper? Is a PEP necessary?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19065
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19065] sqlite3 timestamp adapter chokes on timezones

[R. David Murray]

R. David Murray added the comment:

Can you expand on why you are -1, Gerhard?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19065
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19065] sqlite3 timestamp adapter chokes on timezones

[Gerhard Häring]

Gerhard Häring added the comment:

I'm -1 on adding timezone to the adapters.

--
assignee:  - ghaering

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19065
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Convert between timezones

[Akira Li]

Thomas 'PointedEars' Lahn pointede...@web.de writes:

 [X-Post  F'up2 comp.unix.shell]

 Chris Angelico wrote:

 On Fri, Jul 31, 2015 at 6:15 PM, Cameron Simpson c...@zip.com.au wrote:
 Actually, bash has no timezone support but the date command _does_, and
 probably neither better nor worse than Python. All one has to do is set
 the TZ environment variable, eg (untested):

  _year_gmt=$( TZ=GMT date +%Y )
 
 That's assuming that it's converting against the current system
 timezone. I don't know how you'd use `date` to convert between two
 arbitrary timezones. […]

 With POSIX date(1), ISTM all you could do is set the system time and for an 
 additional invocation the TZ variable accordingly for output.

 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html

 With GNU date(1):

 $ (tz_source=Asia/Dubai; time_source=$(LC_TIME=C TZ=$tz_source date -d 
 today 00:00 UTC+4 -Im); tz_target=America/Chicago; echo When it was 
 $time_source in $tz_source, it was $(LC_TIME=C TZ=$tz_target date -d 
 $time_source) in $tz_target.)
 When it was 2015-07-31T00:00+0400 in Asia/Dubai, it was Thu Jul 30 15:00:00 
 CDT 2015 in America/Chicago.

 $ date --version
 date (GNU coreutils) 8.23
 […]


Here's a corresponding Python code. I haven't seen the beginning of the
discussion. I apologize if it has been already posted:

  #!/usr/bin/env python
  from datetime import datetime
  import pytz # $ pip install pytz
  
  source_tz, target_tz = map(pytz.timezone, ['Asia/Dubai', 'America/Chicago'])
  d = datetime.now(source_tz) # the current time in source_tz timezone
  midnight = source_tz.localize(datetime(d.year, d.month, d.day), is_dst=None)  
  
  fmt = %Y-%m-%dT%H:%M:%S%z
  print(When it was {:{fmt}} in {}, it was {:{fmt}} in {}.format(
  midnight, source_tz.zone, target_tz.normalize(midnight),
  target_tz.zone, fmt=fmt))

Output:

  When it was 2015-08-01T00:00:00+0400 in Asia/Dubai, it was
  2015-07-31T15:00:00-0500 in America/Chicago





-- 
https://mail.python.org/mailman/listinfo/python-list

Convert between timezones (was: How to re-write this bash script in Python?)

[Thomas 'PointedEars' Lahn]

[X-Post  F'up2 comp.unix.shell]

Chris Angelico wrote:

 On Fri, Jul 31, 2015 at 6:15 PM, Cameron Simpson c...@zip.com.au wrote:
 Actually, bash has no timezone support but the date command _does_, and
 probably neither better nor worse than Python. All one has to do is set
 the TZ environment variable, eg (untested):

  _year_gmt=$( TZ=GMT date +%Y )
 
 That's assuming that it's converting against the current system
 timezone. I don't know how you'd use `date` to convert between two
 arbitrary timezones. […]

With POSIX date(1), ISTM all you could do is set the system time and for an 
additional invocation the TZ variable accordingly for output.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html

With GNU date(1):

$ (tz_source=Asia/Dubai; time_source=$(LC_TIME=C TZ=$tz_source date -d 
today 00:00 UTC+4 -Im); tz_target=America/Chicago; echo When it was 
$time_source in $tz_source, it was $(LC_TIME=C TZ=$tz_target date -d 
$time_source) in $tz_target.)
When it was 2015-07-31T00:00+0400 in Asia/Dubai, it was Thu Jul 30 15:00:00 
CDT 2015 in America/Chicago.

$ date --version
date (GNU coreutils) 8.23
[…]

:)

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue19065] sqlite3 timestamp adapter chokes on timezones

[Jacques-D. Piguet]

Jacques-D. Piguet added the comment:

I just hit the problem in Python 2.7.
The patch given here is not applicable due to missing class datetime.timezone 
in Python before 3.2.

Question 1: when will the patch be applied in Python 3?
Question 2: any chance to get a solution in Python 2?

--
nosy: +jacques-piguet
type: enhancement - crash

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19065
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Timezones

[Seymore4Head]

On Mon, 6 Oct 2014 13:48:58 +1100, Chris Angelico ros...@gmail.com
wrote:

On Mon, Oct 6, 2014 at 1:37 PM, Rustom Mody rustompm...@gmail.com wrote:
 My advice is to avoid time zones, they're a real pain, seriously.

 What say we send an application to the UN to declare the world flat?

Easier to simply start scheduling things in UTC. I run an
international Dungeons  Dragons campaign with sessions every Sunday
at 02:00 UTC, and nobody needs to be confused by time zones. (The
server displays UTC time, so it's easy for anyone to see; for
instance, it's now Mon 02:48:09, so session time was about this time
yesterday.) Civil time can do whatever it likes, just as long as
everyone knows that the meeting is based on UTC.

ChrisA

And I just found out there is going to be another Y2K in 2038.  I hope
I am around to see it.  I spend this Y2K in Las Vegas.

Las Vegas is one of the last few time zones so TVs everywhere were
showing the ringing in of the New Year and nothing was exploding.
-- 
https://mail.python.org/mailman/listinfo/python-list

Timezones

[Seymore4Head]

This is not a new video, but it is new to me.
https://www.youtube.com/watch?v=-5wpm-gesOY

Any links to some easy to follow time zone math?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Timezones

[Mark Lawrence]

On 05/10/2014 22:17, Seymore4Head wrote:

This is not a new video, but it is new to me.
https://www.youtube.com/watch?v=-5wpm-gesOY

Any links to some easy to follow time zone math?



My advice is to avoid time zones, they're a real pain, seriously.

--
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

Re: Timezones

[Akira Li]

Seymore4Head Seymore4Head@Hotmail.invalid writes:

 This is not a new video, but it is new to me.
 https://www.youtube.com/watch?v=-5wpm-gesOY

 Any links to some easy to follow time zone math?

The point of the video is that you should not do it yourself, use
already written tools.

It is quite comprehensive video. Here's how the mentioned issues could
be resolved:

- erratic UTC offset changes by politicians in different countries --
  *use UTC timezone* for calculations, in addition (if necessary) store
  both the local time and timezone info. *Use pytz module* that provides
  access to the tz database to convert between timezones (many people
  get it wrong but it is not a rocket science). As said in the video, it
  won't help if the rules change a day before the DST transition but at
  least most [1] systems will be consistent. It also doesn't support
  some exotic timezone rules such as in Saudi Arabia (sunrise and/or
  sunset at the fixed local time every day [2]) or many timezones before
  1970.

- julian, gregorian calendars, proleptic UT (past dates): *use proleptic
  gregorian calendar (datetime module)* unless you know that you need
  otherwise (then you could investigate what JD means in a particular
  document given multiple possible interpretations)

- leap seconds (posix, Mills, Windows(ntp), smear (google, java)),
  right timezones, and the difference between UT1, UTC(BIMP), GPS,
  TT(TAI), TCB, etc time scales: *ignore them* unless you know that you
  need otherwise e.g., legally elapsed seconds [3]. Here's some pictures
  to illustrate the difference between time scales [4].

[1] http://www.iana.org/time-zones/repository/tz-link.html
[2] https://github.com/eggert/tz/blob/master/asia#L2439
[3] http://www.ucolick.org/~sla/leapsecs/epochtime.html
[4] http://www.ucolick.org/~sla/leapsecs/deltat.html


--
Akira

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Timezones

[Rustom Mody]

On Monday, October 6, 2014 3:45:44 AM UTC+5:30, Mark Lawrence wrote:
 On 05/10/2014 22:17, Seymore4Head wrote:
  This is not a new video, but it is new to me.
  https://www.youtube.com/watch?v=-5wpm-gesOY
  Any links to some easy to follow time zone math?

 My advice is to avoid time zones, they're a real pain, seriously.

What say we send an application to the UN to declare the world flat?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Timezones

[Chris Angelico]

On Mon, Oct 6, 2014 at 1:37 PM, Rustom Mody rustompm...@gmail.com wrote:
 My advice is to avoid time zones, they're a real pain, seriously.

 What say we send an application to the UN to declare the world flat?

Easier to simply start scheduling things in UTC. I run an
international Dungeons  Dragons campaign with sessions every Sunday
at 02:00 UTC, and nobody needs to be confused by time zones. (The
server displays UTC time, so it's easy for anyone to see; for
instance, it's now Mon 02:48:09, so session time was about this time
yesterday.) Civil time can do whatever it likes, just as long as
everyone knows that the meeting is based on UTC.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Improving support for timezones in Python (was: UTC timezone causing brain explosions)

[Ben Finney]

Ben Finney ben+pyt...@benfinney.id.au writes:

 Time zones are a hairy beast to manage, made all the more difficult
 because national politicians continually fiddle with them which means
 they can't just be a built-in part of the Python standard library.

PyCon 2013 had a good talk on calendaring and timezone issues
URL:http://www.pyvideo.org/video/1765/blame-it-on-caesar-what-you-need-to-know-about-d
(video at URL:https://www.youtube.com/watch?v=GBKqRhn0ekM).

The speaker, Lennart Regebro, maintains a library for getting the local
timezone URL:https://pypi.python.org/pypi/tzlocal, and is currently
working on a PEP to improve timezone support directly in the standard
library URL:http://www.python.org/dev/peps/pep-0431/.

He also reinforces the message that UTC is the canonical timezone for
storing and manipulating timestamp values, and we should be converting
to/from those canonical values as early/late as possible in our programs.

-- 
 \ “Reality must take precedence over public relations, for nature |
  `\cannot be fooled.” —Richard P. Feynman |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improving support for timezones in Python (was: UTC timezone causing brain explosions)

[Chris Angelico]

On Fri, Jan 31, 2014 at 1:26 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 He also reinforces the message that UTC is the canonical timezone for
 storing and manipulating timestamp values, and we should be converting
 to/from those canonical values as early/late as possible in our programs.

Call it a UTC Sandwich, like Ned Batchelder's Unicode Sandwich.
It's a good idea for the same reason.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Logging timezones

[Joseph L. Casale]

The default converter attribute uses localtime, but often under windows when
I add an additional logger, create a new file handler and set a formatter the 
time
switches to utc.

Obviously redefining a new converter class does nothing as the default is what I
wanted to start with, localtime.

Anyone experienced this and have a workaround?

Thanks,
jlc
-- 
https://mail.python.org/mailman/listinfo/python-list

Confused about timezones

[Skip Montanaro]

This isn't really a Python issue, though my problem solution will be
implemented in Python. If I have a naive datetime object for some time
in the past, it's not clear to me how the offset gets set correctly.
Consider this sequence:

 import datetime, pytz
 LOCAL_TZ = pytz.timezone(os.environ.get('TZ', America/Chicago))
 dt1 = datetime.datetime(2013, 5, 30, 0, 0) # DST in effect
 dt2 = datetime.datetime(2013, 1, 30, 0, 0) # no DST
 LOCAL_TZ.localize(dt1).utcoffset()
datetime.timedelta(-1, 68400)
 LOCAL_TZ.localize(dt2).utcoffset()
datetime.timedelta(-1, 64800)

Why is the UTC offset the same for both datetime objects despite the
presence/absence of Daylight Savings?

Thx,

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused about timezones

[Skip Montanaro]

 LOCAL_TZ.localize(dt1).utcoffset()
 datetime.timedelta(-1, 68400)
 LOCAL_TZ.localize(dt2).utcoffset()
 datetime.timedelta(-1, 64800)

 Why is the UTC offset the same for both datetime objects despite the
 presence/absence of Daylight Savings?

Brain freeze! A quick glance told me they were the same, when they
actually are different (68400, 64800). Sorry for the needless noise.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused about timezones

[Ethan Furman]

On 10/23/2013 12:00 PM, Skip Montanaro wrote:



-- LOCAL_TZ.localize(dt1).utcoffset()
datetime.timedelta(-1, 68400)
-- LOCAL_TZ.localize(dt2).utcoffset()
datetime.timedelta(-1, 64800)

Why is the UTC offset the same for both datetime objects despite the
presence/absence of Daylight Savings?


Brain freeze! A quick glance told me they were the same, when they
actually are different (68400, 64800). Sorry for the needless noise.


Don't feel too bad, doesn't look like anybody else noticed either!  ;)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list