Re: [Python-Dev] Status on PEP-431 Timezones
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 will clear up during the implementation. //Lennart ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
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:
>
> One solution most of the time
>
> Zero solutions when we "spring forward" -- i.e. there is no 2:30 am
> on March 8, 2015 in the US timezones that use DST
>
> Two solutions when we "fall back", i.e. there are two 2:30 am Nov 1, 2015
> in the US timezones that use DST
>
> But I can't see where there are multiple solutions the other way around --
> doesn't a given UTC time map to one and only one "wall time" in a given
> timezone?
>
> 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 equation.
In that equation I considered loc (the geographical place) and lt (the time
on the clock tower) to be known and t (the universal (UTC) time) to be
unknown. A solution to the equation is the value of the unknown (t) given
the values of the knowns (loc and lt).
The rest of your exposition is correct including "a given UTC time maps to
one and only one 'wall time' in a given timezone." 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.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
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 equation. > > In that equation I considered loc (the geographical place) and lt (the > time on the clock tower) to be known and t (the universal (UTC) time) to be > unknown. A solution to the equation is the value of the unknown (t) given > the values of the knowns (loc and lt). > > The rest of your exposition is correct including "a given UTC time maps to > one and only one 'wall time' in a given timezone." 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) and utc_time = f( location, utc_time ) These are two different problems, and one is much harder than the other! (though both are ugly!) you can, of course shoreten the names to "wall" and "utc" and "loc" if you like, but I kind of like long, readable names.. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
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 defines a function wall(loc, t). This function is a piece-wise
> linear function which may have regular or irregular discontinuities.
>
got it.
> 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:
One solution most of the time
Zero solutions when we "spring forward" -- i.e. there is no 2:30 am
on March 8, 2015 in the US timezones that use DST
Two solutions when we "fall back", i.e. there are two 2:30 am Nov 1, 2015
in the US timezones that use DST
But I can't see where there are multiple solutions the other way around --
doesn't a given UTC time map to one and only one "wall time" in a given
timezone?
Am I wrong, or is this a semantic question as to what "wall" time means?
Thanks for any clarification,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
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) > > and > > 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 last equation, but that would still be wrong. A somewhat more correct equation would be utc_time = f^(-1)( location, wall_time) where f^(-1) is the inverse function of f, but since f in not monotonic, no such inverse exists. Finding the inverse of f is the same as solving the equation f(x) = y for any given y. If f is such that this equation has only one solution for all possible values of y then an inverse exists, but this is not so in our case. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
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. got it. I suggest you perhaps word it something like: wall_time = f( location, utc_time) and 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 last equation, but that would still be wrong. A somewhat more correct equation would be utc_time = f^(-1)( location, wall_time) where f^(-1) is the inverse function of f, but since f in not monotonic, no such inverse exists. Don't you mean "f⁻¹"? :-) Finding the inverse of f is the same as solving the equation f(x) = y for any given y. If f is such that this equation has only one solution for all possible values of y then an inverse exists, but this is not so in our case. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones
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 last > equation, > oops, yes. > but that would still be wrong. > > A somewhat more correct equation would be > > utc_time = f^(-1)( location, wall_time) > In this case I meant "f" as "a function of", so the two fs were not intended to be the same. Yes, one is the inverse of another, and in this case the inverse is not definable (at least not uniquely). I have no doubt you understand all this (better than I do), I'm just suggesting that in the discussion we find a way to be as clear as possible as to which function is being discussed when. But anyway -- thanks all for hashing this out -- getting something reasonable into datetime will be very nice. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python3 Stable ABI
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 the script finds is actually exported as part of the limited API, but due to not being in the .def file it's not actually exported from python3.dll. Almost all of the differences are things that the script found that weren't present, but there are a couple things going the other way. The point of this message is to ask everybody who maintains anything in C to take a look through and make sure everything in their area is properly guarded (or not) by Py_LIMITED_API. Alternately, if somebody can find a bug in my script and brain that's finding too much stuff, that would be great too. Ideally, after this is all settled I'd like to add the script to both the Makefile and the Windows build system, such that PC/python3.def is always kept up to date and flags changes that weren't meant to be made. Regards, -- Zach (I'm afraid Gmail might mangle this beyond recognition, you can find the diff at http://bugs.python.org/review/23903/diff/14549/PC/python3.def if it does.) diff -r 24f2c0279120 PC/python3.def --- a/PC/python3.defMon Apr 13 15:51:59 2015 -0500 +++ b/PC/python3.defMon Apr 13 16:10:34 2015 -0500 @@ -1,13 +1,15 @@ ; This file specifies the import forwarding for python3.dll ; It is used when building python3dll.vcxproj +; Generated by python3defgen.py, DO NOT modify directly! LIBRARY"python3" EXPORTS + PyAST_FromNode=python35.PyAST_FromNode + PyAST_FromNodeObject=python35.PyAST_FromNodeObject + PyAST_Validate=python35.PyAST_Validate PyArg_Parse=python35.PyArg_Parse PyArg_ParseTuple=python35.PyArg_ParseTuple PyArg_ParseTupleAndKeywords=python35.PyArg_ParseTupleAndKeywords PyArg_UnpackTuple=python35.PyArg_UnpackTuple - PyArg_VaParse=python35.PyArg_VaParse - PyArg_VaParseTupleAndKeywords=python35.PyArg_VaParseTupleAndKeywords PyArg_ValidateKeywordArguments=python35.PyArg_ValidateKeywordArguments PyBaseObject_Type=python35.PyBaseObject_Type DATA PyBool_FromLong=python35.PyBool_FromLong @@ -39,7 +41,6 @@ PyCFunction_GetFlags=python35.PyCFunction_GetFlags PyCFunction_GetFunction=python35.PyCFunction_GetFunction PyCFunction_GetSelf=python35.PyCFunction_GetSelf - PyCFunction_New=python35.PyCFunction_New PyCFunction_NewEx=python35.PyCFunction_NewEx PyCFunction_Type=python35.PyCFunction_Type DATA PyCallIter_New=python35.PyCallIter_New @@ -58,6 +59,7 @@ PyCapsule_SetPointer=python35.PyCapsule_SetPointer PyCapsule_Type=python35.PyCapsule_Type DATA PyClassMethodDescr_Type=python35.PyClassMethodDescr_Type DATA + PyCmpWrapper_Type=python35.PyCmpWrapper_Type DATA PyCodec_BackslashReplaceErrors=python35.PyCodec_BackslashReplaceErrors PyCodec_Decode=python35.PyCodec_Decode PyCodec_Decoder=python35.PyCodec_Decoder @@ -68,6 +70,7 @@ PyCodec_IncrementalEncoder=python35.PyCodec_IncrementalEncoder PyCodec_KnownEncoding=python35.PyCodec_KnownEncoding PyCodec_LookupError=python35.PyCodec_LookupError + PyCodec_NameReplaceErrors=python35.PyCodec_NameReplaceErrors PyCodec_Register=python35.PyCodec_Register PyCodec_RegisterError=python35.PyCodec_RegisterError PyCodec_ReplaceErrors=python35.PyCodec_ReplaceErrors @@ -122,6 +125,7 @@ PyErr_Fetch=python35.PyErr_Fetch PyErr_Format=python35.PyErr_Format PyErr_FormatV=python35.PyErr_FormatV + PyErr_GetExcInfo=python35.PyErr_GetExcInfo PyErr_GivenExceptionMatches=python35.PyErr_GivenExceptionMatches PyErr_NewException=python35.PyErr_NewException PyErr_NewExceptionWithDoc=python35.PyErr_NewExceptionWithDoc @@ -132,14 +136,25 @@ PyErr_PrintEx=python35.PyErr_PrintEx PyErr_ProgramText=python35.PyErr_ProgramText PyErr_Restore=python35.PyErr_Restore + PyErr_SetExcFromWindowsErr=python35.PyErr_SetExcFromWindowsErr + PyErr_SetExcFromWindowsErrWithFilename=python35.PyErr_SetExcFromWindowsErrWithFilename + PyErr_SetExcFromWindowsErrWithFilenameObject=python35.PyErr_SetExcFromWindowsErrWithFilenameObject + PyErr_SetExcFromWindowsErrWithFilenameObjects=python35.PyErr_SetExcFromWindowsErrWithFilenameObjects + PyErr_SetExcInfo=python35.PyErr_SetExcInfo + PyErr_SetExcWithArgsKwargs=python35.PyErr_SetExcWithArgsKwargs PyErr_SetFromErrno=python35.PyErr_SetFromErrno PyErr_SetFromErrnoWithFilename=python35.PyErr_SetFromErrnoWithFilename PyErr_SetFromErrnoWithFilenameObject=python35.PyErr_SetFromErrnoWithFilenameObject + PyErr_SetFromErrnoWithFilenameObjects=python35.PyErr_SetFromErrnoWithFilenameObjects + PyErr_SetFromWindowsErr=python35.PyErr_SetFromWindowsErr + PyErr_SetFromWindowsErrWithFilename=python35.PyErr_SetFromWindowsErrWithFilename + PyErr_SetImportError=python35.PyErr_SetImportError PyErr_SetInterrupt=python35.PyErr_SetInterrupt PyErr_SetNone=py
