Proposal-temporal: Should we support alternate ways of telling time?

[sffc]

We allow custom calendars to use different fields for specifying a date (for example, the Japanese calendar can add era). However, according to #389, days are unconditionally defined as solar days on Earth, primarily so that we can have a 1-to-1 mapping with the ISO calendar system.

Should we allow calendars that use alternate ways of telling time within the solar day? For example, maybe a calendar uses something other than hours, minutes, and seconds for subdividing the day. I have heard of such calendars, but I don't know specific examples off the top of my head.

Additional Context: https://github.com/tc39/proposal-temporal/pull/520/files#r412515900

[ryzokuken]

Let's discuss this over the meeting, shall we?

[ptomato]

Meeting, May 7: Temporal won't support it at this time, but we'll take a future-proof approach by changing the names of the calendar methods to have date in them, so that we can later add time methods if a use case for this presents itself.

Action for @sffc, to make this change in the calendar explainer.

[jasonwilliams]

What’s keeping this issue open?

[sffc]

Action for @sffc, to make this change in the calendar explainer.

[ptomato]

Happy to take this one as well, I'm on a closing-issues spree

[pipobscure]

The decision here was based purely on not having use-cases. This needs revisiting.

[ptomato]

Can you say more about the use cases so that we can discuss what changes will be necessary?

[sffc]

I'm open to revisiting this discussion, but I would like to very strongly suggest that we do so with the following parameter: we retain "days" as a universal unit with the same length in all calendars. This assumption is what has enabled us to perform 1-to-1 conversion between calendar systems and ISO-8601, which is the basis of the Temporal data model. In other words, it's totally okay with me if the calendar redefines how the clock works, as long as the clock is periodic each ~ISO day~ _solar day_.

[justingrant]

it's totally okay with me if the calendar redefines how the clock works, as long as the clock is periodic each ISO day.

@pipobscure, how does your NYSE calendar example handle weekends and holidays? Does a "day" span long weekends (breaking @sffc proposed requirement above), or is every day the same length as the America/New_York civic day but simply offset by a fixed number of hours as @sffc is recommending above?

Also @sffc this won't work for a Hebrew religious calendar where days are different lengths. Were these kinds of calendars already out of scope?

One option would be for the calendar itself to have a boolean flag, naming annotation, or some other way for Temporal to know if a Temporal.Calendar's days are always the same length, and conversions could throw if not. This kind of calendar metadata might be a good idea regardless, as some apps may be incapable of handling some attributes of some calendars, so having some sort of feature detection seems useful-- not just for varying day length but perhaps for other things, e.g. varying # of months per year, days not starting at midnight, etc.

[sffc]

Also @sffc this won't work for a Hebrew religious calendar where days are different lengths. Were these kinds of calendars already out of scope?

Not completely true. Let me clarify. All I care about is that a day is a solar day; the solar days need not be the same length, as long as there are the same number of them after the Earth goes all the way around the sun. A traditional Hebrew calendar is fine, as long as each day is mapped to an ISO day; it is typical to map Hebrew to Gregorian according to the date at noon.

So, for example, right now the sun is up, and it is 2020-09-07 for me. Therefore, 2020-09-07;u-ca=hebrew is equal to 18 Elul 5780. However, if we are mapping a whole date time, and the time is after sunset, say, 2020-09-07T21:00;u-ca=hebrew, the Hebrew representation of the date need not match the one where the time is not given.

Again, the purpose of this assumption is to make the ISO data model for Date, MonthDay, and YearMonth work across calendar systems. If we want to relax this assumption, e.g., to support Martian days or Lunar days, then we need to go back to the drawing board on the data model for Date, MonthDay, and YearMonth.

[justingrant]

Again, the purpose of this assumption is to make the ISO data model for Date, MonthDay, and YearMonth work across calendar systems. If we want to relax this assumption, e.g., to support Martian days or Lunar days, then we need to go back to the drawing board on the data model for Date, MonthDay, and YearMonth.

Makes sense. We should find out from @pipobscure whether the NYSE calendar skips weekends or has day-by-day mapping to the ISO calendar.

[pipobscure]

It skips. The “Monday” begins on Friday at 5pm NY.

[ptomato]

Today the Ethiopian calendar was mentioned as an example of a calendar that does this. Here's a page with more information: http://mela.ertale.com/blog/?p=365 (unfortunately, the GitHub repo is gone)

[ptomato]

Meeting, Sept. 17: We do need this for the Ethiopian calendar, but reiterated that this is explicitly not supporting alternate timekeeping systems (e.g. TAI, Mars time, etc.)

[ptomato]

From #882,

When we add dateTimeFromFields, there should be a default implementation such that you can implement only dateFromFields and not have to touch the time portion if your custom calendar doesn't deal with time.

[ptomato]

I'm not actively working on this yet, so unassigning it. I still plan to work on it if no one else does by the time I get to it.

[ptomato]

Auto-closed, but still needs follow ups for documentation and spec text

[ptomato]

Meeting, Nov. 12: Based on reexamining of the use cases (see #1087 and https://unicode-org.atlassian.net/browse/CLDR-9716) we are not certain that we've properly understood how time calendars should be implemented and have decided to leave them out of the current proposal.

Things to consider:

• Nearly everyone agrees that time calendars need more research. It could be that they need to be combined with date calendars, or it could be that they need to be orthogonal, or it could be that they will never be added.
• Leaving out the calendar property of PlainTime and adding one later could break the web.
• @pipobscure feels strongly that PlainTime should keep the calendar property and have it be fixed to one value, and a future revision could either allow other calendars or remove the property, both of which would be web-compatible. Adding other calendars could break existing code, but only if the developer opted in to receiving PlainTimes with non-ISO calendars.
• @sffc feels strongly that PlainTime should remove the calendar property because otherwise we don't provide an ergonomic solution to combining dates with times, and solutions harmful for l10n such as with({ ...time.getFields(), calendar: undefined }) will proliferate on Stack Overflow.

This is a solution that we believe addresses everyone's concerns:

• Add PlainDateTime.withPlainDate(), PlainDateTime.withPlainTime(), ZonedDateTime.withPlainDate(), and ZonedDateTime.withPlainTime() to address the use case of combining dates and times without spreading. These methods use the 'consolidate' behaviour for calendars (throw if non-ISO and different).
• Remove Calendar.timeFromFields(), Calendar.timeAdd(), Calendar.timeUntil(), Calendar.hour(), ..., Calendar.nanosecond().
• Remove PlainTime.withCalendar().
• Remove the calendar argument from PlainTime constructor.
• Throw if there's a non-ISO calendar passed to PlainTime.from().
• The value of PlainTime.calendar is always the ISO calendar.
• Leave the names of the slots, the properties returned from PlainTime.getFields() and PlainTime.getISOFields().

[justingrant]

One note to add to above now that #1087 is closed:

• plainTime.toPlainDateTime(plainDate), plainDate.toPlainDateTime(plainTime), and their ZDT counterparts should all use the 'consolidate' behaviour for calendars (throw if non-ISO and different). This means that withTime and withDate act the same as toPlainDateTime and toZonedDateTime.

[ptomato]

One more amendment, I'm assuming we will remove now.plainTime(), and for maximum forward compatibility we should not rename plainTimeISO to plainTime?

[justingrant]

One more amendment, I'm assuming we will remove now.plainTime(), and for maximum forward compatibility we should not rename plainTimeISO to plainTime?

There is no plainTime on now, at least according to the docs: https://tc39.es/proposal-temporal/docs/now.html#plainTimeISO

It's a bummer that we're committing to a strange name for the "get the current local time" API in return for a potential future feature that we know will be rarely used even in the future. But I guess it's at least consistent with the pattern used elsewhere where any time developers want the "normal" result they'll need to stick an "ISO" at the end of the method name. :-(

[ptomato]

I think that was an oversight in the docs, it was present in the polyfill.

[sffc]

It seems kind-of silly that we have a calendar slot on PlainTime that doesn't do anything.

I'm okay with Temporal.now.plainTimeISO(). Both "plain" and "ISO" are superfluous.

[ryzokuken]

One more amendment, I'm assuming we will remove now.plainTime(), and for maximum forward compatibility we should not rename plainTimeISO to plainTime?

SGTM