On Thu, Apr 16, 2015 at 1:14 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Apr 15, 2015 at 4:46 PM, Akira Li 4kir4...@gmail.com wrote:
Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were
moved back one hour. So times like 01:30 AM happened
On Fri, Apr 17, 2015 at 8:19 PM, Akira Li 4kir4...@gmail.com wrote:
Can you demonstrate that email.utils.localtime does not behave as
documented?
No need to be so defensive about it.
There is nothing defensive in my question. I simply don't understand
what you are complaining about other
Alexander Belopolsky alexander.belopol...@gmail.com writes:
Sorry for a truncated message. Please scroll past the quoted portion.
On Thu, Apr 9, 2015 at 10:21 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Apr 9, 2015 at 4:51 PM, Isaac Schwabacher
Alexander Belopolsky alexander.belopol...@gmail.com writes:
...
For most world locations past discontinuities are fairly well documented
for at least a century and future changes are published with at least 6
months lead time.
It is important to note that the different versions of the tz
On Wed, Apr 15, 2015 at 4:46 PM, Akira Li 4kir4...@gmail.com wrote:
Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were
moved back one hour. So times like 01:30 AM happened twice there on that
day. Let's see how Python handles this situation
$ TZ=Europe/Kiev
On Mon, Apr 13, 2015 at 1:24 PM, Chris Barker chris.bar...@noaa.gov wrote:
Because of these discontinuities, an equation wall(loc, t) = lt may
have 0, 1
or 2 solutions.
This is where I'm confused -- I can see how going from wall time
(local time, etc) to UTC has 0, 1, or 2 solutions:
Sorry to be brain dead here, but I'm a bit lost:
On Fri, Apr 10, 2015 at 4:32 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
For any given geographical location, loc, and a moment in time t expressed
as UTC time, one can tell what time was shown on a local clock-tower.
This
On Mon, Apr 13, 2015 at 2:05 PM, Chris Barker chris.bar...@noaa.gov wrote:
However, different UTC times may map to the same wall time and some
expressible wall times are not results of a map of any UTC time.
got it. I suggest you perhaps word it something like:
wall_time = f( location,
On Mon, Apr 13, 2015 at 10:45 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
Am I wrong, or is this a semantic question as to what wall time means?
You are right about what wall() means, but I should have been more
explicit about knowns and unknowns in the wall(loc, t) = lt
On 2015-04-13 20:14, Alexander Belopolsky wrote:
On Mon, Apr 13, 2015 at 2:05 PM, Chris Barker chris.bar...@noaa.gov
mailto:chris.bar...@noaa.gov wrote:
However, different UTC times may map to the same wall time and
some expressible wall times are not results of a map of any
On Mon, Apr 13, 2015 at 12:14 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
utc_time = f( location, utc_time )
These are two different problems, and one is much harder than the other!
(though both are ugly!)
You probably meant utc_time = f( location, wall_time) in the
On Fri, Apr 10, 2015 at 6:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
It actually took me a long time to understand that the isdst flag in
this context related to the following chain of reasoning:
1. Due to various reasons, local time offsets relative to UTC may change,
thus repeating
12 matches
Mail list logo
