anatoly techtonik techto...@gmail.com added the comment:
Adding Alexander as ISTM he may be interested to read the time discussion.
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The latest patch will produce wrong results if the file was last modified
before timezone rules changed in your location. See issue1647654.
--
assignee: - belopolsky
dependencies: +No obvious and correct way to
anatoly techtonik techto...@gmail.com added the comment:
So, what about 2.7 ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
___
___
Brian Curtin cur...@acm.org added the comment:
2.7 is now frozen as far as new features go. It's still good for 3.2.
I think this is ready to go, so I'll probably commit it later in the day.
--
versions: -Python 2.7
___
Python tracker
anatoly techtonik techto...@gmail.com added the comment:
I still do not understand your policy - it is a tool, it is not a part of
standard library.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
anatoly techtonik techto...@gmail.com added the comment:
Ok. Let's commit it at least to 2.7 - I'll create a separate issue for
discussion of unified diff format later.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
Barry A. Warsaw ba...@python.org added the comment:
This seems like a new feature to me so I'm removing 2.6 from the list. My
browser won't let me remove Python 3.1.
--
nosy: +barry
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
Changes by Brian Curtin cur...@acm.org:
--
keywords: +needs review
type: behavior - feature request
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
___
anatoly techtonik techto...@gmail.com added the comment:
I use this tool in instructions how to generate patches on windows, so I am
interested to see this fix in the version, that users will likely to use for
next couple of years, but I'd be happy to see this committed in any branch.
If it
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I'd like to propose to change default diff format to unicode as well
What kind of unicode format is it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
anatoly techtonik techto...@gmail.com added the comment:
I am sorry - too much windows to reply. This must be *unified*, of course.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
___
anatoly techtonik techto...@gmail.com added the comment:
So, is that right that even if time.daylight specifies the offset, this doesn't
mean that this offset is active?
MS documentation you referenced is unclear: The _get_daylight function
retrieves the number of hours in daylight saving
anatoly techtonik techto...@gmail.com added the comment:
You are right.
[pydst.py]--
import time
print time.asctime()
print time.localtime().tm_isdst
print time.daylight
Tue Feb 09 10:31:47 2010
0
1
Sun May 09 10:33:20 2010
1
1
There is already an issue #7229 to
anatoly techtonik techto...@gmail.com added the comment:
Finally! (I really hope so)
--
Added file:
http://bugs.python.org/file16184/diff.py_iso_timestamps_true_with_true_dst.diff
___
Python tracker rep...@bugs.python.org
anatoly techtonik techto...@gmail.com added the comment:
Brian, documentation says quite the opposite.
time.daylight
Nonzero if a DST timezone is defined.
http://docs.python.org/library/time.html?highlight=daylight#time.daylight
--
___
Python
Brian Curtin cur...@acm.org added the comment:
The documentation could use some work. It means that if the timezone does use a
daylight savings time period, time.daylight specifies the amount of the offset.
In my timezone this value is 1. However, time.localtime().is_dst is currently
0,
Brian Curtin cur...@acm.org added the comment:
http://msdn.microsoft.com/en-us/library/2t504ch6%28VS.80%29.aspx has some info
for how this is implemented on Windows, and I get the same results on my Mac.
On Linux an AttributeError is raised time.struct_time not having an attribute
is_dst,
Brian Curtin cur...@acm.org added the comment:
Whoops, nevermind the Linux comment on that last one. My typo there caused the
exception. The result there is the same as the other platforms.
--
___
Python tracker rep...@bugs.python.org
anatoly techtonik techto...@gmail.com added the comment:
New version detects DST using time.daylight flag.
utcoffset = -(time.altzone if time.daylight else time.timezone) // 60
--
Added file:
http://bugs.python.org/file15798/diff.py_iso_timestamps_true_with_dst.diff
Brian Curtin cur...@acm.org added the comment:
Using time.daylight is incorrect. time.daylight specifies the number of hours
that the daylight offset is, not a flag to specify whether or not daylight
savings time is in effect.
Steven's suggestion of using time.localtime().tm_isdst seems to be
Steven Rumbalski steven.rumbal...@fiserv.com added the comment:
I think this is incorrect during daylight savings time:
tzoffset = -time.timezone // 60
This should do it:
isdst = time.localtime().tm_isdst
tzoffset = -(time.altzone if isdst else time.timezone)//60
--
nosy: +srumbalski
Brian Curtin cur...@acm.org added the comment:
Look at time.timezone -
http://docs.python.org/library/time.html#time.timezone
# I'm in US Central time, so it's -6 from UTC
import time
tz = time.timezone
tz
21600
tz / 60 / 60
6
--
nosy: +brian.curtin
anatoly techtonik techto...@gmail.com added the comment:
Thanks! Now the most elegant patch I could think out.
--
Added file: http://bugs.python.org/file15688/diff.py_iso_timestamps_true.diff
___
Python tracker rep...@bugs.python.org
Brian Curtin cur...@acm.org added the comment:
Looks cleaner and works for me.
One very minor comment: the spaces inside the parenthesis on the
time.localtime call are inconsistent and don't comply with PEP-8.
--
___
Python tracker
anatoly techtonik techto...@gmail.com added the comment:
Pepeighfied and regenerated. Should be flawless now.
--
Added file: http://bugs.python.org/file15689/diff.py_iso_timestamps_true.diff
___
Python tracker rep...@bugs.python.org
Changes by anatoly techtonik techto...@gmail.com:
Removed file: http://bugs.python.org/file15688/diff.py_iso_timestamps_true.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7582
___
New submission from anatoly techtonik techto...@gmail.com:
make diff.py produce unified diffs with ISO 8601 timestamps
Currently generated timestamps are difficult to separate from filename
when parsing if you don't know that the diff was generated by diff.by
This patch make diff.py output
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Using ISO format certainly makes sense, but it seems to me that after
dt=datetime.fromtimestamp(mtime), dt.tzinfo is always None, so the test is
not necessary.
--
nosy: +amaury.forgeotdarc
anatoly techtonik techto...@gmail.com added the comment:
That's true. Is there any way to get current TZ offset in Python? I can't
find anything better than datetime.datetime.now() -
datetime.datetime.utcnow() and then rounding to a nearest minute.
--
29 matches
Mail list logo
