Temporal

Update 2019-10-02

  • Process & Progress
  • Objects & Decisions
  • Actions & Roadmap

Notes

Temporal

Process & Progress

  • Stage-1: specify a design
  • Stage-2: validate the design
  • Stage-3: implement the specification
  • Stage-4: mandate a the specification

Temporal

Process & Progress

Stage-2 Progress

create polyfill
publish polyfill (github & npm)
invite feedback/reviews (bloomberg, google, moment, luxon, tag, public)
incorporate feedback
update stakeholders
finalize specification
tc39 stage review

Temporal

Objects & Decisions

  • Absolute: An absolute point on the timeline
  • DateTime: A human representation of untethered date & time
    • Date: The date aspect of a DateTime
      • YearMonth: A partial aspect of a Date
      • MonthDay: A partial aspect of a Date
    • Time: The time aspect of a DateTime
  • TimeZone: A representation of time-rules
  • Duration: a length of time used for arithmetic

Temporal

Objects & Decisions

  • Absolute: I was born 1976-11-18T14:23:00Z
  • DateTime: TC39 meeting in Nov-2020 starts 2020-11-16T10:00:00
    • Date: This TC39 meeting began 2019-10-01
      • YearMonth: TC39 met in 2019-01, 2019-03, 2019-06, 2019-07, 2019-10
      • MonthDay: Brendan Eich's birthday is 07-04
    • Time: TC39 meetings begin at 10:00:00
  • TimeZone: This TC39 meeting is in America/New_York
  • Duration: TC39 meets for 7 hours today PT7H

Temporal

Objects & Decisions: Should there be a Combination Type

graph LR; timezone(Time-Zone); subgraph " "; absolute(Absolute); end; subgraph " "; datetime(DateTime); date(Date); yearmonth(YearMonth); monthday(MonthDay); time(Time); datetime --- date; datetime --- time; date --- yearmonth; date --- monthday; end; absolute === timezone; timezone === datetime;

Temporal

Objects & Decisions: Should there be a Combination Type

graph LR; zoned[ZonedAbsoluteDateTime?] timezone(Time-Zone); subgraph " "; absolute(Absolute); end; subgraph " "; datetime(DateTime); date(Date); yearmonth(YearMonth); monthday(MonthDay); time(Time); datetime --- date; datetime --- time; date --- yearmonth; date --- monthday; end; absolute === timezone; timezone === datetime; zoned --- absolute; zoned --- timezone; zoned --- datetime;

Temporal

Objects & Decisions: Should there be a Combination Type

Option A: No Combination Type

Pro:

does not mandate basing on absolute or calendar time
works when time-zone rules change

Con:

does not provide a practical all-round object

Temporal

Objects & Decisions: Should there be a Combination Type

Option B: ZonedDateTime

Pro:

works when time-zone rules change
provides all-round type

Con:

not inline with ISO-8601 which pins offset

Temporal

Objects & Decisions: Should there be a Combination Type

Option C: ZonedAbsolute

Pro:

coherent with ISO-8601 schema
provides all-round type

Con:

fails when time-zone rules change

Temporal

Objects & Decisions: Should there be a Combination Type

Option D: both ZonedDateTime & ZonedAbsolute

Pro:

provides full set of all-round types
can work for most circumstances

Con:

unclear that there are decisions to be made
easier to make bad assumptions

Temporal

Objects & Decisions: Should there be a Combination Type

Suggested Answer: Option A

  • the benefit of all-round type(s) is wiped out by unexpected behaviour
  • programmers are free to combine as they they need
  • making explicit choices is better than unexpected consequences
  • canonical practice can be advised via MDN etc.

Drop combination type and encourage programmers to make explicit choices

Temporal

Objects & Decisions: Global Namespace Object

We will continue under the premise of Temporal becoming a namespace object on the global.

Given that:

  • Unsolved how loading auxiliary modules (Intl for Temporal) works
  • Javascript Standard Library: currently at Stage-1

we feel like Temporal is not a good candidate for a first built-in module at thid time.

Temporal

Objects & Decisions: Exposing system information

Biggest feedback: access to system information is required

  • current date/time
  • current time-zone
  • time-zone validity

How can we give access to current system date/time & time-zone, while still meeting the requirements of SES and other like implementations?

Temporal

Objects & Decisions: Exposing system information

Balancing act between:

securing implementations / eliminating idiosynchatice timing leaks
making the environment easy and useful to programmers

Temporal

Objects & Decisions: Exposing system information

Proposed Compromise

constructors are unable to expose system information
group all functions exposing information
make explicit all places that need mitigation

Temporal

Objects & Decisions: Interoperability with Intl

  • we have been cooperating with ECMA402 & Shane
  • we think we've found a way to make Temporal objects just work
  • there's a spec PR regarding this

Temporal

Actions & Roadmap

incorporate decisions & feedback
release updated polyfill to npm
request further community review
finalize specification
tc39 stage review / edit specification to reflect
request tc39 stage advancement

Temporal

Actions & Roadmap

(2019-10-31) incorporate decisions & feedback
(2019-10-31) release updated polyfill to npm
(2019-10-31) request further community review
(2019-12-31) finalize specification
(2019-12-31) tc39 stage review / edit specification to reflect
(2020-02-04) request tc39 stage advancement

mermaid.js 12.1.0