What should be the long-term name of LocalDateTime ?

[justingrant]

In #700, @InExtremaRes asked:

@justingrant Hi. I'm curious, why do you pick LocalDateTime as a name? If ZonedDateTime haven't been "occupied", were you choose that instead? I know you said is just a placeholder name, but I'd like to know your rationale behind that as, you know, names communicates a lot the intentions of a model.

I figure this won't be the last question/suggestion about the name of this type, so opening up this issue to coalesce feedback about naming. The current name is just a placeholder.

[justingrant]

Copying from #700:

@InExtremaRes - Great question. I avoided Zoned* names because of the historical baggage, because this type (like @pipobscure noted) wasn't a close match to those earlier proposals, and finally because a goal of this type is to be friendly and enticing for new users who may not know which Temporal type is the right one for their use case. "Zoned" is not particularly friendly, and it's not even a real English word so isn't obvious for new users. "Local" is a familiar word that has the connotation of "in a particular place" which is closer to what I was hoping to achieve with a name. But really I just wanted a non-confusing placeholder until we had time to pick a final name.

That said, a concern I have with LocalDateTime as a long-term name is that Java uses the same name for its equivalent of Temporal's DateTime. So developers coming from Java might get confused.

When it comes time to pick the final name, I think it'd be helpful to consider both this type and the DateTime type's names together. IMHO, a goal of naming both these types should be to encourage new users who don't know Temporal to use LocalDateTime instead of DateTime, because the former type is safe for DST and the latter is not. So ideally, LocalDateTime would have a short and friendly name and DateTime would have a longer and/or less-friendly name.

Ironically, I have a stronger opinion about the name of DateTime, which I'd like to see as "ZonelessDateTime" or "PlainDateTime" or something like that that would make noobs think twice before using it.

For LocalDateTime, I don't have a great idea yet for what should be the final name. Feedback appreciated!

[gilmoreorless]

I've followed this proposal from the start, but had to focus on other things for the past couple of months. I'm finally catching back up and was very surprised to see the LocalDateTime name had come back. I'm especially surprised that it's come back in a form that's the opposite of how it was previously used (as LocalDateTime was one of the alternative naming options for CivilDateTime, which was later renamed to just DateTime once it was put under the Temporal namespace). As you pointed out, it's also in conflict to how the name LocalDateTime is used in Java.

Naming is important, and definitely hard, as all the previous bikeshedding issues and PRs about names have shown. The prior discussions most relevant to this particular issue are:

• #11: Calling types not tied to a specific location "local"
• #33: Bikeshed thread for civil time prefix
• #144: Redefine civil.md

A particularly noteworthy comment is at #11 (comment):

It is also important to note that the alternative names are all negative BTW - "zoneless", "raw", "plain", "naive", "just", "only". Naming a class after what it is not is IMO a Bad Idea.

Personally, I don't see what's wrong with the name ZonedDateTime; it's a DateTime that is tied to a specific Zone. I have to disagree with your assertion in #700:

"Zoned" is not particularly friendly, and it's not even a real English word so isn't obvious for new users.

There are several points to make about this:

1. The entire concept of handling dates and times correctly, accounting for all possible footguns, isn't obvious for new users. This was best put by @jskeet in Calling types not tied to a specific location "local" #11 (comment):

In terms of the argument about it making it blindingly obvious: I believe the idea that anyone will come to a date/time library and be able to make the right decisions without reading any documentation is simply unrealistic. Whatever it's named, users will have to read docs. If there's a name which isn't hugely obvious before you've read the docs, but is fine when you have read the docs, that seems reasonable to me

2. Leaving aside semantics of the phrase "not a real word", "zoned" is categorically a defined English word. It's the past tense of the verb "zone", and is quite appropriate for this use case. Ref 1, Ref 2.

---

As a side note... I always liked the concept of a zoned date-time object (the previous ZonedDateTime and your current LocalDateTime). I never fully agreed with the reasoning/justification for dropping the old ZonedDateTime, because major API decisions were being made without any practical examples of how they affected common use cases. Now that we have the cookbook examples, better decisions can be made. Thank you for putting in the effort to make this concept work. 😁

[pipobscure]

@gilmoreorless welcome back. I fully agree with you. I think the name is definitely a placeholder only 😄

[justingrant]

Yep, the current name is just a placeholder. My suggestion is to defer the naming question for a few weeks while we define exactly how this new type will behave and how it will relate to other Temporal types. Also IMHO it will be helpful for folks to have a little time to play around with LocalDateTime sample code to get a real-world sense of how the type will be used.

Depending on the above, some names may be more or less appropriate. Also, I suspect that it will be a lot easier to get consensus on naming once we have consensus on scope/behavior/etc.

This is a nice way of suggesting that we don't cover the type-naming question in tomorrow's marathon meeting. ;-)

[ptomato]

I'm fine with LocalDateTime → DateTime and DateTime → something else (PlainDateTime, AbstractDateTime, CalendarDateTime)
Another choice could be "Event" in line with the description of it as an event that happened at a particular time in a particular place.

[justingrant]

I'm fine with LocalDateTime → DateTime and DateTime → something else (PlainDateTime, AbstractDateTime, CalendarDateTime)

Agreed. I'd add ZonelessDateTime to the "something else" list, with the goal of helping users understand that it's the type to use when you want the date and time but don't don't know (or don't care about) the time zone. PlainDateTime is a more subtle version of the same idea; you only need something "plain" if the "full" (or spicy!) thing is not available or appropriate.

I'd avoid Calendar* because it'd imply that types without that prefix don't use calendars.

Another choice could be "Event" in line with the description of it as an event that happened at a particular time in a particular place.

I agree in principle, but "Event" is used in the web platform (e.g. DOM events) to mean "something that happened in an interrupt-driven fashion" without LocalDateTime's emphasis on "in a real place". So I'd be inclined to avoid "Event" in Temporal to avoid that potential confusion.

[pipobscure]

Beware IF we were to go and rename DateTime to “something else” we’d also have to rename Date and Time (and possibly MonthDay and YearMonth) for consistency.

[pipobscure]

Also LocalDateTime is so much more than just a Date and Time that I’m not convinced that’s the way to go.

How about the other extreme: AbsoluteZonedDateTime

And in literature we can refer to it by its nickname: AZDT 😀

[ptomato]

Beware IF we were to go and rename DateTime to “something else” we’d also have to rename Date and Time (and possibly MonthDay and YearMonth) for consistency.

I disagree, I wouldn't see a problem with having e.g. DateTime, PlainDateTime, Date, and Time. My reasoning is that there's no possibility to have a 'spicy' (as Justin put it) Date and Time.

Also LocalDateTime is so much more than just a Date and Time that I’m not convinced that’s the way to go.

Fair enough, something else along the lines of Event would satisfy that concern, but 👎 to AZDT 😄

[sffc]

Some ideas.

Option 1: Based on the Data Model

Current Temporal Name	New Temporal Name
DateTime	DateAndTime
LocalDateTime	LocalTimestamp
Absolute	Timestamp

These names accurately reflect the data model, which I think can help developers think about the relationship between these types more effectively. I expanded "DateTime" to "DateAndTime" to make it look less friendly.

Option 2: Java-style

Current Temporal Name	New Temporal Name
DateTime	LocalDateTime
LocalDateTime	ZonedDateTime
Absolute	Instant

These names are based on the equivalent types in java.time.

Option 3 : Based on function

Current Temporal Name	New Temporal Name
DateTime	CivilDateTime
LocalDateTime	DateTime Event
Absolute	Timestamp

These names are intended to reflect the use cases. DateTime Event is your go-to choice when you want to represent an instant specific to a place and calendar system. CivilDateTime is a weird version of DateTime without a time zone.

EDIT 2020-09-02: I changed "DateTime" to "Event" to more accurately reflect the mental model.

[justingrant]

I'm seeing several folks above mention this pattern:

1. LocalDateTime => DateTime
2. DateTime => XxxDateTime, where Xxx could be "Zoneless", "Plain", "Civil", "Abstract", etc.

Seems like a good pattern for discoverability, IMHO. I support this pattern. I don't have a strong opinion about Xxx, but I tried to order them above in my (slightly) preferred order.

[ptomato]

👎 Zoneless, Civil, Theoretical, Nonlocal, Ideal, Wall
😐 Plain, Pure, Relative
👍 Abstract, Calendar

edit: I've kind of come around to AbstractDateTime. I also still like CalendarDateTime because it's the most descriptive of the names, in my opinion, although I will definitely concede that it's confusing because it implies that the other types don't have calendars.

[pipobscure]

Consistency is key, so if we end up renaming DateTime with something else so as to make DateTime available for this, then that means the same schema applies to Date and Time.

So we’re back at prefixing the basic types (DateTime , Date & Time) just to benefit something that is more specialized and thereby suggesting its use for cases it unsuited for.

For those reasons I’m against prefixing the current objects and for contemplating suitable names for LocalDateTime only.

Given it’s decided semantics as some event on the absolute timeline in sone specific place I find LocalDateTime quite appropriate. Alternatively ZonedDateTime is a contender. Optimally we’d have a simple (i.e. non-compounded) name like Event (which is ruled out, but like it). Maybe TimeEvent or EventTime or Occurrance?

[sffc]

What I posted above as Option 1 is currently my favorite. #707 (comment)

DateTime becomes DateAndTime, for reasons I've discussed previously: DateTime is an overloaded term in programming, so in my opinion, it is a good idea not to use that term at all. We can use DateAndTime to emphasize the nature of this type.

LocalDateTime becomes LocalTimestamp (or LocalAbsolute), accurately reflecting its data model. I like the prefixed "Local" instead of "Zoned" because the type also carries a calendar, not just a time zone, relative to the regular Timestamp/Absolute. "Local" reflects that this is a localized timestamp in multiple ways.

[ljharb]

It will be very awkward to have a conjunction in the name; “DateAndTime” seems like a poor choice.

[ptomato]

First choice: A name like Event. EventTime and Occurrence are not quite it, but maybe we can come up with one? Could we actually reuse Instant for this, or even Moment (with apologies to moment.js)? (Thesaurus suggests some others that I don't like: Incident? Happening? Circumstance? Occasion?)

Second choice: LocalDateTime → DateTime, DateTime → AbstractDateTime. (I disagree that this would make it necessary to rename Date and Time as well. It's not possible to have a zoned Date or a zoned Time, so there's no ambiguity.)

Last choice: use the Java names but keep Timestamp instead of Instant.

I think "Local" and "Civil" had already been rejected years ago for good reasons, and especially Local could be argued to be a good name for (the types that are currently called) LocalDateTime or DateTime.

[pipobscure]

Second choice: LocalDateTime → DateTime, DateTime → AbstractDateTime. (I disagree that this would make it necessary to rename Date and Time as well. It's not possible to have a zoned Date or a zoned Time, so there's no ambiguity.)

It’s not about ambiguity, it’s about consistency. It makes AbstractDateTime seem different from Date and Time where it is very similar and it make (Local)DateTime seem similar to Date and Time where it is very different. It also puts (Local)DateTime into a spot of pre-eminence it’s not properly in.

For all these reasons (and a few I haven’t thought of yet) this is option 100 in my order of preference right after naming all out classes Temporal.0 through Temporal.9

[pipobscure]

I think "Local" and "Civil" had already been rejected years ago for good reasons, and especially Local could be argued to be a good name for (the types that are currently called) LocalDateTime or DateTime.

Local was dismissed for the classes that currently live without a prefix. For the current LocalDateTime it’s actually appropriate. Civil was only dismissed because it became unnecessary to prefix given a Temporal global object, so I’d say it’s definitely in the game.

As a matter of fact I’d like to suggest not changing the name of LocalDateTime at all, or if so then changing the DateTime part rather than the Local part. So how about LocalEvent?

[justingrant]

I think it'd be helpful to be explicit about the prioritization framework we're using to guide our preferences. Here's mine, in ranked order:

1. Ecosystem Reliability, which IMHO here means preventing users from assuming that the type currently named DateTime will adjust for DST. Since I first joined this project this has been my top reliability concern with Temporal. Even experts can make this mistake, e.g. Default Date.toDateTime() argument to midnight #860 (comment). FWIW, concern about the DST bugs this mistake would cause is the main reason I've spent the last few months helping to flesh out the LocalDateTime proposal!
2. Discoverability / Learnability. Make it obvious to new users what use cases each type should be used for, ideally by picking words that already have meaning for desired use cases of each type and (just as important) don't have meaning for use cases we want users to avoid for each type. In other words: maximize recognition while minimizing ambiguity.
3. Ergonomics, which for type names really means short and easy to spell
4. Consistency which I see primarily as a means to an end to achieve the priorities above. It's possible to make things more consistent but harder to use, so ideally we'd avoid that kind of consistency. ;-)

With these priorities in mind, my current preference is:

• DateTime => CivilDateTime OR DateTime => ZonelessDateTime (prefer the latter, but both are OK)
• LocalDateTime => DateTime
• Leave Date, Time, MonthDay, YearMonth as-is

Why?

• "Civil" is the clearest possible term for experts. It's what Wikipedia calls this concept!
• "Civil" is a completely unknown term for non-experts, so will discourage accidental use of any type with this prefix.
• I also like ZonelessDateTime because it also solves the problem of preventing accidental use (esp. by non-experts) while being super-obvious what use cases it should be used for. I actually prefer this more than CivilDateTime because it will be more discoverable for non-experts who occasionally have the need for a zoneless type, but it's also unpopular among the Champions. So I'm happy to follow the wisdom of the crowd between these two names because my top concern (accidental use causing DST bugs) will be addressed either way.
• Date, Time, etc. have no corresponding DST-unsafe type that we need to scare novices away from, so IMHO adding a prefix (especially a prefix that's explicitly designed to discourage use!) would unnecessarily impede higher-priority Discoverability and Ergonomics goals for those types.

But honestly I care more about the priorities than specific names. I'd be happy with other names that fulfill the same goals.

[sffc]

@justingrant Do you feel that my proposed LocalDateTime => LocalTimestamp and DateTime => DateAndTime (or perhaps CivilDateTime in light of @ljharb's comment) satisfies your priorities?

1. Ecosystem Reliability: We eliminate a type named DateTime.
2. Discoverability / Learnability: Most users should arrive at LocalTimestamp, because Timestamp doesn't have datetime fields and CivilDateTime or DateAndTime sounds scary. The type names are self-explanatory of their data model.
3. Ergonomics: I think LocalTimestamp is easy enough to spell.
4. Consistency: Not sure what you mean by this, but the type names are consistent with their data model.

I can also see some merits about naming the types based on the mental model / intended use case (e.g. Event).

[sffc]

Why I'm not super fond of LocalDateTime => DateTime:

1. "DateTime" is an overloaded term in this industry that is likely to bring problematic preconceptions about what the type is supposed to do.
2. The name "DateTime" corresponds to neither the data model (timestamp+timezone+calendar) nor the mental model (an event that occurred at a place).

[justingrant]

@justingrant Do you feel that my proposed LocalDateTime => LocalTimestamp and DateTime => DateAndTime (or perhaps CivilDateTime in light of @ljharb's comment) satisfies your priorities?

Nope. I think LocalTimestamp is actually worse than neutral because "Timestamp" implies (and will be documented as) "a machine-readable thing that doesn't have a date or a time". Attaching an ambiguous word like "Local" (does it mean "my time zone"? "anyone's time zone?" "no time zone?") to it won't undo the core problem that the word "Timestamp" would actively impede users from thinking that it'd work for their Date/Time use cases. FWIW, I picked the name "LocalDateTime" as a placeholder name specifically because it was so ambiguous so no one would think it was meant to be the final name. ;-)

The fact that LocalDateTime is implemented using a timestamp is really just an implementation detail. From the user's perspective, a LocalDateTime is a date, a time, an offset, and a time zone. Using at least some of those words in the name will help discoverability. And if the zoneless type has "Date" and "Time" in the name and the zoned type does not, it's perhaps the worst possible discoverability outcome.

"DateTime" is an overloaded term in this industry that is likely to bring problematic preconceptions about what the type is supposed to do.

I'm not sure this is a bad thing. Discoverability workflows have 1-2 steps:

• "initial discoverability" - this is mainly whether the name of something corresponds to the name of some other familiar thing, either in plain English or in another programming context. Ideally, there's one obvious initial choice for most/all popular use cases.
• "subsequent discoverability" - if the initial thing isn't right for your use case, does your first pick help you get closer to the next one, and so on until you find the best one for your use case? Or does it take you to a dead end where you need to back up and start over? This is why I like DateTime for the zoned type and XxxDateTime for the zoneless type, because in the less-common case where you really want a zoneless type, your first pick will help you find it.

Here's another way to think about the discoverability process:

• The best outcome is when your initial choice is right.
• The second-best outcome is when your initial choice makes it easy for you to discover the right choice in an obvious way. For example, if you try to parse a bracketless string into a zone-required type called DateTime and you get an exception complaining that the time zone is missing, this is a pretty good signal about how the type works and about what your likely next steps could be (e.g. add a time zone, find a zoneless type, etc.)
• The third-best outcome is when there's no obvious initial choice and you must read the docs for all types to find the right one.
• The worst outcome is when your initial choice seems like the right one so you stop looking for the right one. This outcome doesn't just make discoverability harder. It also breaks software. strcpy vs strncpy in C is a good example. I'd argue that string.prototype.toUpperCase vs. string.prototype.toLocaleUpperCase is another. So is, IMHO, DateTime and ZonedDateTime.

Anyway, I see DateTime for a zoned type as either the first or second outcome in the list above. Either the user knows the time zone and will be happy, or they don't and they'll be quickly guided (by exceptions, error messages, IDE parameter help, etc.) to look for the correct type for their use case.

FWIW, Joda Time (which was the basis of Java.time) used DateTime for the name of the zoned type before the Java folks renamed it to ZonedDateTime. So there's at least some precedent for DateTime to mean a zoned type.

BTW, although I prefer DateTime for the zoned type and either ZonelessDateTime or CivilDateTime (or any other XxxDatteTime) for the zoneless one, a distant second choice that I like better than all the others proposed so far would be ZonedDateTime and ZonelessDateTime. I don't like how this pair is less opinionated about which type to try first; I suspect this would make it less good at the #1 "reliability" item in my priority list. And it's less ergonomic (#3). But Zoned/Zoneless is very discoverable (#2) and very consistent (#4).

[sffc]

Attaching an ambiguous word like "Local" (does it mean "my time zone"? "anyone's time zone?" "no time zone?") to it won't undo the core problem that the word "Timestamp" would actively impede users from thinking that it'd work for their Date/Time use cases.

But I belive the charter of LocalDateTime is to represent an event (timestamp) that occurred at a particular location (time zone and calendar system). The fact that it works nicely with date/time timezone math is a convenient afterthought.

The fact that LocalDateTime is implemented using a timestamp is really just an implementation detail. From the user's perspective, a LocalDateTime is a date, a time, an offset, and a time zone.

I disagree with that premise. Unlike what's currently called DateTime, a LocalDateTime represents an unambiguous instant in time; it just has a location (time zone and calendar system) attached to it. It's a fallacy to think of it as a date, time, offset, and time zone, because not every combination of those elements can be represented by a LocalDateTime (say 2:30am the night of a spring forward DST transition).

[justingrant]

But I believe the charter of LocalDateTime is to represent an event (timestamp) that occurred at a particular location (time zone and calendar system). The fact that it works nicely with date/time timezone math is a convenient afterthought.

I actually wasn't thinking of math here. I was more thinking about Date and Time fields. Many developers wouldn't expect a type named "XxxTimestamp" to have those fields.

But I also think it's fine to think of it as an Absolute+TimeZone. Both viewpoints are correct, which I actually think is an advantage of LDT because I expect both viewpoints will be present among users of Temporal. Some developers will naturally gravitate to one view or the other, and I think that's OK.

BTW, this reminds me of an insight I heard from an old colleague that I think applies here:

• Experienced, systems-level developers tend to approach programming like physicists: from the inside out. They start with the conceptual framework and how things work under the hood. For these folks, "What is it?" is the most important question.
• On the other hand, junior developers tend to approach new APIs like a child with a new toy. They look at the outside to see what knobs and switches there are, and then they start pushing buttons to see what happens. "What does it do?" is the important question for them. Only later after using it for a while do they fully understand the underlying concepts.

Anyway, my point in the comment above was that from the junior-developer POV of looking at the outside of the type, LDT feels more like today's DateTime and less like today's Absolute. For these developers, the word "Timestamp" would make it harder to discover this type.

It's a fallacy to think of it as a date, time, offset, and time zone, because not every combination of those elements can be represented by a LocalDateTime (say 2:30am the night of a spring forward DST transition).

I don't think I agree with this statement. Aggregates can place restrictions on their content without invalidating the essence of the combination. A userland Fraction type composed of two Number fields isn't a fallacy if its author decides that its constructor should throw if the divisor is zero.

[sffc]

The "What is it?" versus "What does it do?" insight is very relevant here.

I actually wasn't thinking of math here. I was more thinking about Date and Time fields. Many developers wouldn't expect a type named "XxxTimestamp" to have those fields.

I want programmers to think about date getters as being tied to the calendar system. Types that carry a calendar are equivalent to those that have date getters and support date math.

"LocalTimestamp" is descriptive, because "local" suggests both a time zone and a calendar system. When I was chatting with Ujjwal the other day, I suggested that we could name the Absolute -> LDT transition function "localize", taking the two arguments (time zone and calendar), to emphasize what "local" means.

For comparison, I wouldn't like "ZonedTimestamp", because it suggests a Timestamp+TimeZone data model; however, we made the very significant decision to also include a Calendar in the LDT data model. Similarly, "CalendaredTimestamp" is misleading because it does not indicate the presence of a time zone.

[pipobscure]

While I’m Ok with Timestamp for what is currently called Absolute I strongly oppose it for this.

LocalDateTime is NOT a Timestamp attached to a Timezone in any but meaning but the datamodel we happen to choose for the polyfill.

I also don’t care about what the current experts in the field think too much. And here is why:

Experts in any field retire and get old and new ones grow. As such “what is expected and known” is actually not that important because it changes over time. For example when I was young literally literally meant literally but these say the meaning has changed to figuratively and we no longer have a word meaning literally.

Much more important is the mental mode we establish and that this is internally consistent. If we do that, then the coming generations of experts in the field have a much easier time to emerge.

Our mental model is that:

• Absolute is an absolute fixed moment in time
• Date is a wall-calendar (like the one hung in my kitchen)
• Time is a wall-clock
• DateTime is a wall-clock hung next to a calendar
• LocalDateTime is a date and time carefully adjusted to a timezone so as to match it.

Just because there is a randomness factor introduced called DST that makes that date & time & timezone tuple not entirely unambiguous therefore forcing us to use an absolute in the polyfill does not change that mental model.

So while at the start LocalDateTime was named thinking that’ll not be its name, that very name has helped shape the thing as well. So I’d still urge us to consider it.

So as a matter of fact the statement:

But I belive the charter of LocalDateTime is to represent an event (timestamp) that occurred at a particular location (time zone and calendar system). The fact that it works nicely with date/time timezone math is a convenient afterthought.

is entirely misguided in my view. On the contrary:

the charter of LocalDateTime is to attach a date and time to a timezone. The fact that moves it so close to representing a timestamp (only requiring a bit of disambiguation) and the fact that unambiguous values are important anyhow make using an Absolute in the datamodel an after thought for the polyfill.

[justingrant]

Meeting 2020-20-15: "Plain" wins! Also we'll use that same prefix on MonthDay and YearMonth too for consistency.

Final names are: ZonedDateTime, PlainDate, PlainTime, PlainDateTime, PlainYearMonth, PlainMonthDay

EDIT: conversion methods will also be renamed, e.g. toDate => toPlainDate.

[sffc]

What did we decide for the conversion methods within the Plain space?

1. Temporal.PlainDateTime.prototype.toDate()
2. Temporal.PlainDateTime.prototype.toPlainDate()

[justingrant]

Hmm, we didn't talk about that, but I think it'd be Temporal.PlainDateTime.prototype.toPlainDate(). Otherwise it'd seem like the conversion should produce a legacy Date.

[ljharb]

I'm confused, why is a twitter poll being used as the deciding factor?

[justingrant]

It's just one factor. All three names polled were ones we thought might work. A non-representative (albeit more representative than Champions+Reviewers+GH-Commenters who are much more sophisticated than the median JS developer) sample of 166 developers preferred "Plain" over the alternatives by a wide margin. This isn't decisive but was a helpful signal that "Plain" would be a widely-acceptable prefix. Looking through the "Other" suggestions on Twitter didn't bring up any other names we thought might be more accepted. Therefore, in today's meeting we were able to get to consensus that "Plain" would be the best choice.

[ljharb]

79 preferred Plain, 30 preferred Floating, 30 preferred Civil. The trend certainly implies this spread, but that's a pretty small sample size and difference. It'd be nice, prior to the relevant plenary, to gather more input about the name (including, ideally, the ability for folks to suggest things).

[pipobscure]

We’ve been through several iterations of this discussion. We’ve changed this a number of times. We’ve also asked the committee for input on a few occasions.

This decision wasn’t left to a poll, but rather we used a poll as the final piece of input to come to a conclusion.

So I’m strictly against revisiting this again. The time for this has passed. We’ll go to the committee and ask for agreement of course. And the committee will then have to come to consensus. If someone wants to withhold consensus due to the name of these classes, then so be it. But until then, revisiting this is not productive.

[ljharb]

I don't believe I asked for anything to be revisited - I asked for more data to be gathered to present to plenary at the appropriate time.

[pipobscure]

Do you have a proposal for how to gather that data?

[sffc]

The trend certainly implies this spread, but that's a pretty small sample size and difference.

There are 11.7 million active JavaScript developers. In our poll, we captured 166 of them. The margin of error of this sample is 8% with 95% confidence. Therefore, Plain has a statistically significant lead.

[ljharb]

@sffc i believe that presumes that the polled population (twitter users who happened to see the poll) does not vary significantly from the larger group of JS developers.

@pipobscure I'm not sure. perhaps a poll that lasts longer than a day or two would help obtain more results, especially if it were posted on multiple venues besides Twitter (not sure if this one was, or not).

[justingrant]

The trend certainly implies this spread, but that's a pretty small sample size and difference.

Statistically, 166 is more than enough for a nearly-3:1 spread to be significant. The sampling method (who's answering) probably introduces far more error than the sample size.

That said, what we've observed from running 3 different naming polls so far is that results don't change much after the first few dozen responses. This was surprising to me. I'd have expected, for example, that developers in North America (who probably saw the poll first) would vote differently from developers in Europe or Asia as they woke up and saw Twitter. Or that initial respondents would more likely to be TC39 or Temporal insiders who'd vote differently from later respondents who were random Twitter followers.

But what we ended up seeing across three polls that results are surprisingly consistent. Here's what this poll returned after only 18 votes. Numbers are within 8% of final results.

Here's what the previous poll was after 40 votes. All choices were within 8% of their final result.

This consistency in geography and insider/outsider has made me more confident than I expected to be that these unscientific Twitter polls are a reasonable approximation of the actual JS developer population. This is nice because launching these polls is so much easier than any other means I've ever used to sample 100s of developers.

FWIW, for a few years in the '00s I ran rolling surveys of 100s of developers per month from a population of 5M+ visitors to MSDN.com. Fielding, reducing errors in, and making sense of developer surveys is a topic I know fairly well from those years. Getting 150+ reasonably-representative responses in 24-48 hours, for free, is an amazing step forward compared to what we had back in the day. My past self is jealous!

[justingrant]

The new name is decided and #700 has been updated with the new name, so I'm going to close this issue. Thanks everyone for your help picking "ZonedDateTime" as the name of this type!

[ptomato]

I'd like to keep this open, the other types still need to be renamed to "Plain", so this is a good issue for anyone to pick up without lots of prior knowledge of Temporal.

[justingrant]

OK sounds good.

[justingrant]

Although, actually: would you be OK if I closed this one and opened up a new issue specifically for the PlainXxx rename? There's no need for someone to read through hundreds of bikeshed comments to pick up that work. ;-)

[ptomato]

Sure, that works too.

[justingrant]

To summarize this issue before closing it, here's the final names that were decided:

LocalDateTime => ZonedDateTime
Date => PlainDate
Time => PlainTime
DateTime => PlainDateTime
YearMonth => PlainYearMonth
MonthDay => PlainMonthDay

#1072 will track the work to rename the unzoned types.