You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
(likeplus
andwith
) to return a single date value, rather than 3 year, month, and day values.Data validity
The
year
,month
, andday
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.The text was updated successfully, but these errors were encountered: