[Datetime-SIG] Clearing up terminology

[Łukasz Rekucki]

On 30 July 2015 at 02:14, Chris Barker <chris.barker at noaa.gov> wrote:
> On Wed, Jul 29, 2015 at 2:31 PM, Felipe Ochoa
>>
>> * local vs global: "The key difference is that people all around the world
>> will agree on a global value simultaneously, whereas they may all see
>> different local values for the same global value, due to time zones." Local
>> values are what Guido has labeled "naive" -- in the sense that they don't
>> have a datetime.
>
>
> Is this a typo? should be "don't have a time zone"? By the way, that means"
> can't map to UTC, which, by extension, means, "can't map to any other
> timezone"

Yes, LocalDateTime does not have a timezone and thus does *not* define
an instant on a timeline. You can't convert it to anything without
providing extra information.

>>
>> * Time zone: "a mapping from UTC instants to offsets"
>
>
> note that the actual mapping may (does) change over history, and has odd
> things like DST.

Yes, that's already covered in this definition. You can also say that
a Timezone is a function from an Instant to offset. An example such
function would look like this:

   def tz_us_cookie_time(instant):
       if instant.year() > 2016:
           return -5000 if 4 < instant.month() < 11 else -6000
       else:
           return tz_us_boring_time(instant)

As the number of rules is always finite, you can also make it a mapping.

>
> This seems like an obviously good idea to me, aside from potential
> implementation difficulty and  I'm not sure if there are backward
> compatibility issues.
>

The backwards incompatibility is that PEP also want that ZonedDateTime
[== datetime(tzinfo=tz("America/Chicago"))] does the sane thing and
follows what NodaTime, JodaTime, etc. does - which is "Time line
arithmetic".


> So is there any more to be hashed out in the PEP (it seem where to get the
> time zone data on Windows is one unresolved issue).
>
> Then there seem to be the big hang-up: people want a way to define Periods
> (as defined above) and want to be able to do datetime math with them. I"m
> still really confused as to why folks seemed to think "time zone aware"
> somehow meant using Peiods rather than Durations for arithmetic, but there
> you go. Clearly this is very useful thing to have, but it's NEW feature, and
> not covered in the PEP.

No, people want to keep adding Durations (timedelta) to ZonedDataTime
and expect it to work in "time zone aware" manner. In particular
adding 24h duration should add exactly 24h, *always*. This is *NOT*
how Python's datetime currently works.