In issue23903, I've created a script that will produce PC/python3.def
by scraping the header files in Include. There are are many many
discrepencies between what my script generates and what is currently
in the repository (diff below), but in every case I've checked the
script has been right: what
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_tim
On 2015-04-13 20:14, Alexander Belopolsky wrote:
On Mon, Apr 13, 2015 at 2:05 PM, Chris Barker 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 UTC
time.
On Mon, Apr 13, 2015 at 2:05 PM, Chris Barker 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, utc_time)
>
> an
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."
>
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(lo
On Mon, Apr 13, 2015 at 1:24 PM, Chris Barker 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:
>
> On
The Open Space was good, and the conclusion was that solution #2
indeed seems to be the right one. We also concluded that likely the
datetime() constructor itself needs to grow an is_dst flag. There was
no further insight into whether having an offset or a is_dst flag as
an attribute, I think that