[Datetime-SIG] Clearing up terminology

[Chris Barker]

On Wed, Jul 29, 2015 at 2:31 PM, Felipe Ochoa <felipe.nospam.ochoa at gmail.com
> wrote:

> Jon Skeet has created what I think would be a very useful guide for people
> on this list to read.
>
> http://nodatime.org/1.2.x/userguide/concepts.html
>
>
>
> TL;DR: here's a glossary of terms:
>

YES! thank you!

I'm not sure I like all the choices here, but  it seems complete and makes
the distinctions that need to be made.

Please let's all start using these terms.

A few comments.


> * 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"

* Instant: a point on the non-relativistic time line. Isomorphic to "the
> number of seconds since the unix epoch". It doesn't make sense to talk
> about time zones with instants
>

>
* Calendar system: a means of breaking up the time line into "units such as
> years, months, days, hours, minutes, and so on"
>
> * 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.


> * Offset: "simply the difference between UTC and local time."
>
> * ZonedDatetime: An instant + a time zone
>
> * OffsetDatetime: An instant + an offset (which is not the same as a
> ZonedDatetime!)
>
> * LocalDatetime: A date/time in the usual "naive" sense: a combination of
> year, month, day, hour, minute, second, millisecond (soon to be nano?)
>
> * Duration: The difference between two instants. "A fixed number of
> ticks". What has also been called "stopwatch deltas". Skeet says, "it's the
> same length of time wherever it's applied. Duration is used for arithmetic
> on Instant and DateTime values."
>
> * Period: "a set of values associated with different calendar-based
> periods: years, months, weeks, days, hours, minutes and so on. Some of
> these periods represent different lengths of time depending on what they're
> applied to."
>

OK -- so, as I read it, the PEP calls for adding pre-defined ?Time Zone
objects -- this is a great idea, sorely needed, despite the maintenance
headache.

It also calls for adding an is_dst flag,so that datetime can completely
support unambiguous transformations both ways to-from UTC.

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.

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.

So -- if someone want to go forward with this, we probably need a new PEP.

In any case, I think that adding the timezone stuff in the current PEP is a
great step forward, and we shouldn't hang that up because we are waiting to
hash out yet more functionality.

-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.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150729/13a3c2f2/attachment.html>