Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use integer DateData and TimeData as internal storage #67

Closed
timrwood opened this issue Jul 18, 2018 · 3 comments
Closed

Use integer DateData and TimeData as internal storage #67

timrwood opened this issue Jul 18, 2018 · 3 comments
Labels
spec-text Specification text involved

Comments

@timrwood
Copy link
Contributor

After thinking through some of the Abstract Operations in the spec, I wondered if it would be simpler to represent a CivilDate as a single [[DateData]] internal slot instead of [[YearData]], [[MonthData]], and [[DayData]] internal slots.

A [[DateData]] value would be an integer representing the number of days since an epoch.

Epochs

If the epoch was the Unix Epoch, something like the MakeDay abstract operation could be used.

Other potential epochs are Jan 1, 4713 BC from Julian Date or Jan 1, 1 from Rata Die.

Simplification of abstract operations

This would allow abstract operations for CivilDate (like plus and with) to return a single date value, rather than 3 year, month, and day values.

Data validity

The year, month, and day accessor properties can be calculated from [[DateData]] using something similar to YearFromTime, MonthFromTime, and DateFromTime.

Invalid dates like '2000-01-32' could not mistakenly be represented, as the year, month, and day are derived from the number of days since the epoch.

Use with other calendars

While other calendars are out of scope for this proposal, supporting them may be possible by using a different implementation of YearFromTime, MonthFromTime, and DateFromTime

Consistency in CivilTime and CivilDateTime

A similar representation could be used for CivilTime, with a [[TimeData]] internal slot instead of [[HourData]], [[MinuteData]], [[SecondData]], [[MillisecondData]], and [[NanosecondData]] internal slots. A [[TimeData]] value would be a positive integer representing the number of nanoseconds since 00:00.

A CivilDateTime could then be represented with [[DateData]] and [[TimeData]] internal slots.

@maggiepint
Copy link
Member

Agree this would reduce spec text duplication. Good call.

@maggiepint
Copy link
Member

Thinking about this more, I believe this method could be used to solve #25 - determine valueOf() and #35 comparison functions. The comparisons for CivilDate/CivilTime/CivilDateTime/Instant can work off of the valueOf which can be derived from this.

Zoned instant still has an open question which is - can we compare zoned instants across time zones

@gibson042 gibson042 added the spec-text Specification text involved label Sep 11, 2019
@pipobscure
Copy link
Collaborator

This is thoroughly obsolete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec-text Specification text involved
Projects
None yet
Development

No branches or pull requests

4 participants