Rename Civil objects to Gregorian

[pipobscure]

We recently had debates on twitter and per phone which expressed a dislike to the prefix Civil to describe the temporal objects. The alternate suggestion was to use Simple or any number of other things.

One more option is to use Gregorian which I'd like to advocate for. The reason I'd like to advocate for that, is because it's clear, it is explicitly for the Gregorian Calendar, and supporting different calendars would be done via different objects. This would allow for big gains now without precluding differing calendars in the future.

I'd also argue that this holds true even for CivilTime (which arguably has no calendar by suggesting that even times are calendar-system dependant.
Take the hebrew calendar as an example. Shabat starts on a Friday at sunset to Saturday at sunset. It could be argued therefore that the time in the hebrew calendar begins/ends at sunset rather than at midnight in the Gregorian calendar. While I'm not an expert in the hebrew calendar, the example goes to show that it is quite reasonable to express even time in terms of the calendar in use.

Feedback/Comments Please

[pipobscure]

@maggiepint @mj1856 @bterlson you were the one kicking of that discussion on Twitter if I recall correctly. Input?

[ljqx]

@pipobscure , I think there are only 2 ways to define a "day" for civil usage: apparent solar time & mean solar time. (There are other ways for other purposes, such as Sidereal Day, Julian day, etc)

For mean solar time (or specifically clock time defined in IEC 60050-111 which is adopted by ISO 8601), as it's (almost) always 24h, no matter when it starts and ends, it's ok to use existing CivilTime. (though the start & end determinate when is "now", like time zone).

For apparent solar time, Hebrew calendar requires time system to be apparent solar time with starting & ending at sunset. But I'm not sure if other calendars have such requirement. And I think actually Gregorian calendar doesn't require the day to be 24-hour clock, this is requirement of ISO 8601.

This International Standard recommends the use of time scales applying the 24-hour time keeping system for the identification of time points within a calendar day.

From the specification 3.2.3 Time scales within the calendar day. This implies that Gregorian calendar doesn't enforce time clock to be 24-hour clock too.

[srl295]

Just to add to the above list: compare with time and day cycle with ethiopian. The time cycle might be considered separate from the calendar cycle.

In any event, perhaps the concept is local time, or wall time. Joda/310 calls these"localtime/localdate" , Unicode TR#35 calls these "wall time"

[pithu]

WallTime great ! Interesting proposal.

[pipobscure]

WallTime would then mean different things in Addis Ababa, in Tel Aviv and in New York. That's precisely why I am proposing GregorianTime.

Now I'm good with not calling it GregorianTime since @ljqx is correct in that the Gregorian Calendar does not require a 24h day starting at midnight. But I think it should be something that indicates clearly that this is just one option among potentially many.

[ljharb]

Isn’t that point? It’s supposed to be a time that means different things depending on where you stand.

[pipobscure]

@ljharb sorry for being unobvious. I picked those cities not because of timezones (where yes you're right), but rather because:

Addis Ababa uses Ethiopian Time (day start with 0:00 at 6AM, day end with 12:00 at 6PM, then 0:00 at 6PM for night until 12:00/00:00 at 6AM for night)

Tel Aviv uses the Hebrew Calendar rather than Gregorian.

So Ethiopian WallTime 10:00DAY would be 16:00 WallTime using standard Midnight-Midnight practice. If we want to enable support for other calendars and time counting methods, then WallTime is a really bad name (slightly worse in fact than CivilTime).

[srl295]

@pipobscure good points. Gregorian may be the clearest, then.

[rxaviers]

Shouldn't "gregorian" be a CivilDate option for "type of calendar"? Something like:

let gregorianCivilDate = new CivilDate(year, month, day, {calendar: "gregorian"});
let hebrewCivilDate = new CivilDate(year, month, day, {calendar: "hebrew"});

Currently, this proposal includes this statement in its principles: "All date values are based on the Proleptic Gregorian Calendar. Other calendar systems are out-of-scope for this proposal. However, we will consider how future APIs may interact with this one such that extending it to support other calendars may be possible in a future
proposal."

It's very unfortunate that a proposal that aims to solve this realm in JavaScript abstains to include other calendars in its scope.

[phueper]

To go full circle... I still prefer Local as used in other projects/languages/specs.. To me it is still the clearest... See #11 (comment)

[zenparsing]

Given existing usage, I also think Local is adequate. It's usually best to not overthink things like this too much. : )

[pipobscure]

I’m actually thinking of implementing HenrewDatetime, HebrewDate and HebrewTime as examples for other calendars/timestyles as well. So to me the current Civil object will only ever deal with Gregorian calendar/24h-midnight based stuff. Which is also why I’ll be proposing to remove ZonedInstant.prototype.toCivilX() methods and instead go for GregorianDatetime.fromZonedInstant() static functions. That way the Instant/ZonedInstant objects are purely non-calendarial, and the GregorianX / HebrewX / ChineseX / EthiopianX objects will be there for different calendars/timestyles. Since they’ll each have a fromZonedInstant() static method and a toZonedInstant() method, changing from one calendar to another will be trivial. And all of that without complicating the GregorianX objects needlessly with options and additional methods/members.

…

On 18 Sep 2018, at 20:11, Kevin Smith ***@***.***> wrote: Given existing usage, I also think Local is adequate. It's usually best to not overthink things like this too much. : ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[phueper]

Maybe i'm totally off here... but in my mind the "LocalTime" (and Date/DateTime/...) thing is just a "container" for hours/minutes/...

I think of it as a clock that has no "engine" ... as long as we agree on 24h/day and 60minutes/hour .. .i can set this clock to some time (8:15) and give it to you and you would also interpret it as 8:15 ... if i tell you "add 120 minutes" you would set it to 10:15 and return it and i would agree that this is correct...

Now without a reference/zone this is all this clock does ... it allows me to define a time and do some math with it... i can diff two times/add them/... the result would always be well defined...

Where is this time on the global timeline? No idea, and no way to tell... and thus i don't see why hebrew/ethiopian/gregorian matter here... as long as 24h/60 min is common... it should work, shouldn't it?
Now... if you add Location/Zone/Reference... it is something totally different... then we might be able to see where this time is on the global timeline and math becomes much more complicated (DST, different day start times, ...) that would be a ZonedTime in my mind and yes, there might be Hebrew/Gregorian/Klingon/... versions of that ...

But again... i might be totally wrong here and you all have a different thing in mind if you talk about this time class... then ignore me.. but ... given my understanding i still find "Local" or "Wall" the best prefix ...

[pipobscure]

@phueper you are correct based on your premises, however your premises are wrong.

There is no agreemenent that a day has 24 hours, that a minute is even a thing much less than an hour has 60 of them, same for seconds. We also don't have agreement that there is even such a thing as months, and if there are how many of them there are and how many days they may contain.

For Instant & ZonedInstant all of that is irrelevant, as they simply are a counter for the number of radian transitions of the Cesium-133 atom relative to a specific point in time, as well as (for ZonedInstant) the geo-offset relative to that.

For CivilDate, CivilTime & CivilDatetime these assumptions are elemental. For those we have agreed that each day has 24 hours with an hour being 60 minutes each of which has roughly 60 seconds (we accept that there may be leapseconds in input that we ignore) based on the proleptic gregorian calendar to define the length of months and years.

What we want to enable is a distinct (and equal) set of classes to handle other cases such as (invented just now)

A day has 100 hours each of which has 100 minutes (potentially fractional). One year is a single
revolution of the earth around the sun and has 36 months each of which contain 10 days. The 37th
month is called XMas and has 4-5 days beginning in what we would consider 16:00 on the 24th of
what we would consider December. Leading to the fact that days begin/end at 16:00 throughout
the year.

I realize this sounds crazy, and I only used it to explain that we want to be able to handle even that kind of thing (albeit in separate classes) but in an equal way to anything else.

More realistically:

• The Ethiopian Day begins at what we what call 6:00. Which means that September 21st 2018 2:30d would mean 2018-09-21T08:30:00. The day only has 12 hours so that September 21st 2018 8:30n would mean 2018-09-22T02:30:00.
• Similar goes for the Hebrew Calendar, although it's not about time, but rather dates this time: The year begins with the 1st of Nisan which has 30 days. The months are then in sequence 29/30/29/30/29/30/29or30/30or29/29/30/29 days long. So any calculation that wants to add a number of days, will not be able to use the current CivilDate objects. In addition, Nisan is roughly on the 16th of March. And that's just the Religious calendar, for civil purposes the year actually begins on the 1st of Tishri, which is roughly September 10th.

I'm ignoring the Chinese calendar (and others) for now, since I'm less familiar with it and these two amply illustrate the issues.

My design goal is to create a set of temporal objects, that allow easy implementation of any calendar and easy interchange between them. At the same time I realise that some calendars are more equal than others. So I want to simply not give the Gregorian calendar with its 24h midnight-midnight day an inherent advantage and make it harder to implement other calendars.

Whence my call to rename these objects. I am also suggesting we remove the ZonedInstant.prototype.toCivilDate(), ZonedInstant.prototype.toCivilTime() and ZonedInstant.prototype.toCivilDatetime() methods in favour of static methods GregorianDate.fromZonedInstant(instant), GregorianTime.fromZonedInstant(instant) and GregorianDatetime.fromZonedInstant(instant).

I also propose (separately from this proposal, but based on it) to implement the Hebrew and Ethiopian classes as "PolyFills" to demonstrate how that would work for other cultures.

[rxaviers]

@pipobscure, a summary of the benefits of your rename proposal (in my understanding):

• Clarity: the existing Civil name prefix and its other candidates (Local, Plain, Unzoned, Simple, etc) have been arguably confusing (or better put, arguably debatable, no clear consensus as Bikeshed thread for civil time prefix #33 and twitter debates show); The Gregorian name prefix is clearer because the existing Civil objects are "explicitly for the Gregorian Calendar" and "supporting different calendars would be done via different objects."
• Support for non-gregorian calendars: your proposal defines how non-gregorian calendars will be supported by Temporal (important addition in my opinion, because so far this hasn't been defined)

[pipobscure]

Thanks @rxaviers for moderating all these issues. You nailed exactly what I was getting at.

[pipobscure]

I'm prepping a presentation on the state of temporal right now.

Can I take it that this is sort-of agreed? - Or I'll have to construct things a bit differently.

[pipobscure]

Please also have a quick look at the relevant spec-text update in #89

[ljqx]

@pipobscure , @srl295 , @rxaviers , @ljharb How about just ISODate, ISOTime & ISODateTime. Then we can still have GregorianDate, HebrewDate, HebrewTime, HebrewDateTime, and avoid to have misleading GregorianTime.

[pipobscure]

I like it since it reflects better what it is as well! Gregorian could actually mislead in context of Ethiopia. There the day begins at our 6am and goes to 6am (both ISO times). So this GregorianDate class would actually be wring there even though they use the Gregorian calendar. Ceterum censeo religiones debent delerentur essent propter perniciosas sunt.

…

On 22 Sep 2018, at 10:18, Remi Liu ***@***.***> wrote: @pipobscure , @srl295 , @rxaviers , @ljharb How about just ISODate, ISOTime & ISODateTime. Then we can still have GregorianDate, HebrewDate, HebrewTime, HebrewDateTime, and avoid to have misleading GregorianTime. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pithu]

You lost me.

Behind the the prefix gregorian, i would expect the historical calendar definition, valid for dates after the year 1582 only. Or maybe a mixture with the julian calendar and this gap in october 1582.
And what the hell is gregorian time ? I never heard that it stands for a 24 hour day with 60 minutes per hour, 60 seconds per minute and nanosenconds, starting a new calendar date at midnight.

I thought you are looking for a name prefix for proleptic Gregorian calendar dates and time as specified at ISO 8601 , but without timezone informations. Gregorian simply does not fit.

And ISO is no option as well, because the unzoned character of the domain is not expressed by that prefix.

[pipobscure]

While ISO allows for inclusion of timezones there are fully valid expressions of dates, times and datetimes as part if the standard. So the ISO prefix works quite well.

…

On 23 Sep 2018, at 11:01, Philipp Thuerwaechter ***@***.***> wrote: You lost me. Behind the the prefix gregorian, i would expect the historical calendar definition, valid for dates after the year 1582 only. Or maybe a mixture with the julian calendar and this gap in october 1582. And what the hell is gregorian time ? I never heard that it stands for a 24 hour day with 60 minutes per hour, 60 seconds per minute and nanosenconds, starting a new calendar date at midnight. I thought you are looking for a name prefix for proleptic Gregorian calendar dates and time as specified at ISO 8601 , but without timezone informations. Gregorian simply does not fit. And ISO is no option as well, because the unzoned character of the domain is not expressed by that prefix. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mattjohnsonpint]

Unfortunately, I am not onboard with either Gregorian or ISO.

• The Gregorian calendar was implemented at too many different dates by different countries, and implies the Julian calendar for earlier dates. We do not want to try to model the cut-over. It needs to remain Proleptic, such to align with ISO 8601 and stay agnostic.

• Gregorian is a calendar descriptor, and has nothing to do with time.

• While we are doing a lot to align with ISO 8601, we shouldn't imply that we are exactly implementing the ISO 8601 spec (we don't have leap seconds, they do, etc.)

• "ISO" doesn't mean just "ISO 8601". Wikipedia reminds us:

  It unified and replaced a number of older ISO standards on various aspects of date and time notation: ISO 2014, ISO 2015, ISO 2711, ISO 3307, and ISO 4031.

• There's no guarantee that there won't be some future ISO date spec that deprecates ISO 8601 in a way that introduces incompatibilities with our stuff.

• ISO and ECMA are different organizations and operate under different principles. While ISO 8601 is a useful alignment, I don't think it's prudent to name standard objects in ECMAScript after the ISO itself.

• ISODate has meaning in MongoDB's JavaScript shell, which is more like our Instant. Calling ours ISODate may create conflicts for some.

As much as I still think my original concerns were valid, I'm now convinced that "local" is really the best option. At least, it's the least problematic of the various options.

[ljharb]

@mj1856 ES does have toISOString(), and is itself an ISO standard, so i think it'd be fine.

[pipobscure]

I agree that "Greogorian" is bad. The issue with "Local" and "Civil" is that it suggests some kind of universality.

These objects do NOT represent "Local" time in Addis Ababa or Tel Aviv or ...

How about ECMADateTime 😆 ?

Few more issues:

1. I want the name to be one that allows for equality of other systems (Hebrew/Ethiopian/Chinese/...)
2. I want a solution asap.

(Though I'm flexible on both as long as there is a coherent mental model / clear reason for it)

[mattjohnsonpint]

These objects do NOT represent "Local" time in Addis Ababa or Tel Aviv or ...

They don't? Are you sure? I'd appreciate some examples, but also let's not confuse "local" for "locale".

FWIW - I'm not sure about Ethiopia, but my understanding is that the Gregorian calendar and a 24 hour clock are used for most activities in Hebrew speaking areas in the world. There are other places in the world that uses different calendar systems, but not many that use different clocks. Some places may align to solar mean time or lunar observations rather than a fixed 24 hour clock, but I don't think we need to account for such things here.

[mattjohnsonpint]

The only potential confusion I see around "local" is that it is not the local time of a given environment, but rather just a local time somewhere in the world. We can document this.

[mattjohnsonpint]

I want the name to be one that allows for equality of other systems (Hebrew/Ethiopian/Chinese/...)

I get that. However, we get much of that from ECMA-402 formatting. It would only make sense for a HebrewDate object to exist, if we wanted to support things such as adding a quantity of Hebrew months. Taken unilaterally, that makes some assumptions about such operations being sensible in all calendars we decide to implement.

As of today, we've already agreed to only support the Proleptic Gregorian calendar anyway.

I want a solution asap.
(Don't we all? 😉 )

[pipobscure]

Example 1: In Addis Ababa the Gregorian calendar is in use. However the day starts at what to us would be 6am and has 24 hours from there. So 2018-09-27T03:00:00.000+03:00 would be expressed as “September 26th 9:00 at night” in “LocalDateTime”. Example 2: Today in Tel Aviv is in “LocalDate” would be 17th Tishrei 5779 and posted as such in government offices. —- What I’m saying is that assuming the Gregorian calendar with a 24h midnight day and calling that “Local” is just a bit chauvinist. Ceterum censeo religiones debent delerentur essent propter perniciosas sunt.

…

On 26 Sep 2018, at 16:04, Matt Johnson ***@***.***> wrote: These objects do NOT represent "Local" time in Addis Ababa or Tel Aviv or ... They don't? Are you sure? I'd appreciate some examples, but also let's not confuse "local" for "locale". FWIW - I'm not sure about Ethiopia, but my understanding is that the Gregorian calendar and a 24 hour clock are used for most activities in Hebrew speaking areas in the world. There are other places in the world that uses different calendar systems, but not many that use different clocks. Some places may align to solar mean time or lunar observations rather than a fixed 24 hour clock, but I don't think we need to account for such things here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mattjohnsonpint]

Aren't those both formatting concerns covered by ECMA-402?

Also, calendars don't define time of day - only year/month/day. If that is indeed the convention used in Addis Abba, I'm not sure how we could possibly capture that in any API. It's not covered in IANA or CLDR data (as far as I am aware). It's a very interesting edge case, but I don't see why that should drive our decisions here.

[mattjohnsonpint]

I understand there are parts of the world where "what time is it" depends heavily on your caste/religion/politics - and that two individuals in the same exact place would not necessarily agree. Again, such things seem out of scope.

[pipobscure]

We have agreed to only deal with the proleptic Gregorian calendar at this point, so as to be able to move forward at all. I’m actually in the process of implementing the Hebrew calendar as well as the Ethiopian version on top of this as a polyfill. This should then enable the next step of a temporal proposal. I’m thinking of this along the lines of the ES6 class proposal. It started out as syntax sugar for function/prototype and we are now building on that. If we make chauvinist decisions now that make it harder to do this later, then I consider this a failure. Ceterum censeo religiones debent delerentur essent propter perniciosas sunt.

…

On 26 Sep 2018, at 16:16, Matt Johnson ***@***.***> wrote: I want the name to be one that allows for equality of other systems (Hebrew/Ethiopian/Chinese/...) I get that. However, we get much of that from ECMA-402 formatting. It would only make sense for a HebrewDate object to exist, if we wanted to support things such as adding a quantity of Hebrew months. Taken unilaterally, that makes some assumptions about such operations being sensible in all calendars we decide to implement. As of today, we've already agreed to only support the Proleptic Gregorian calendar anyway. I want a solution asap. (Don't we all? 😉 ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[maggiepint]

For what it's worth, I don't think using the name Local prevents us from adding types for a different calendar later - so I don't see it as exclusive per-say. It is euro-centric, but the programming language is also in English and we're not debating that yes?

[pipobscure]

Ok. Second question is that "Local" implies a place where it's local to.

The more this discussion goes on, the better I like "Civil" 😄

[mattjohnsonpint]

Ok. Second question is that "Local" implies a place where it's local to.

That was my original, one and only concern. The concerns with the other names seem more numerous and substantial, which led to my point about "a" local vs "the" local. There are lots of local places around the world. It's not unreasonable to take a local value, and another local value, and assert that they are from two different locations. A focus point on this in the spec text is a must.

[pipobscure]

Given this discussion, I think we are better of leaving this alone and retain Civil.

It's better than Local and has less implications. My only complaint with Civil would be that it sounds too generic, but that goes for most of the alternatives as well.

Anyone mind me closing this, with the conclusion:

We retain the naming as Civil and withdraw the issue?

[mattjohnsonpint]

Given this discussion, I think we are better of leaving this alone and retain Civil.

Certainly for the time being. As of today, we are looking to advance to Stage 2 of the ECMAScript proposal process. We don't need to resolve the naming issue until Stage 3.