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.

[sffc]

Adding a prefix to all three types (XxxxDateTime, XxxxDate, XxxxTime) wasn't easy to agree on, but we decided to move forward on that assumption for now and gauge the degree to which the community and the committee strongly disfavor that approach.

There are a lot of reasons why the prefix makes sense. Here are a few:

1. Emphasizes that ZonedDateTime and XxxxDateTime/XxxxDate/XxxxTime are two different "realms" in Temporal.
2. Leaves open the option for third-party libraries, or a potential Temporal follow-up, to add ZonedDate and ZonedTime, which are both well-defined on their own.
3. Minor: Further reduces potential confusion between legacy Date and Temporal.Date. The Temporal prefix already eliminates most of this confusion, but the names being the same may still be confusing to some programmers.

[ljharb]

@pipobscure slippery slope arguments aren't particularly helpful in these kind of discussions, nor do they come off as being in good faith.

[justingrant]

I'll leave it up to others and Twitter to argue about specific prefixes. I don't have a strong opinion although I don't like "naive" either because spelling, connotation, etc.

I'd also strongly prefer (although I was outvoted and don't want to block consensus) no prefix on Date nor Time because I'm concerned that brevity-oriented developers will hate the extra typing and because a prefix isn't strictly needed for disambiguation unlike the two date/time types where at least one must be prefixed.

The only would-block-consensus opinion I have in this discussion is that the zoneless date/time type needs a prefix and should NOT be called "DateTime" w/o a prefix. Here's why:

@ljharb Why would they be blindsided? if they have a timezone, they'd provide it and get an error; if they don't, then it'll be the right term.

The problem is that most developers won't get an error. They'll supply the time zone and it will be ignored, or they won't even realize that the time zone is needed because their linter and/or TS didn't warn them. Instead, their zoneless code will appear to work fine and will pass tests. Then the code will break in production when a DST transition happens. That's bad! Copying from my comment above:

If users aren't sure which date/time type to use, [we should] gently encourage them to try the zoned type first. Why? If a developer picks the zoned type incorrectly, then it's trivial to realize the mistake because [the code will crash on first run]. However, if a developer accidentally picks the zoneless type, then it's easy to miss the mistake until production code breaks at DST transitions. The latter is riskier for the ecosystem, so IMHO we should gently nudge users to try the zoned type first.

TL;DR - if a developer is not sure which type to pick, choosing the zoned type is vastly safer for the developer and for the ecosystem overall because finding "I chose the wrong type" bugs are caught at development time instead of in production.

A sample use case is a "last call skill" on a smart speaker which will automatically announce "last call!" 15 minutes before closing time at a bar. On the Saturday night where DST starts each Spring, a 2:00AM closing time becomes 3:00AM. With the Temporal zoned date/time type, I (correctly) hear the reminder at 1:45AM because the zoned type knows that subtracting minutes should use exact (Instant) math as required by RFC 5545 which is the controlling spec for DST-safe calendar math. However, If I use an unzoned Temporal type, subtract 15 minutes, and then convert to Instant to schedule the reminder, then last call will happen at 3:45AM! Without a unit test for DST transitions, it's likely this bug will never be found before shipping.

Also, in almost every platform that I surveyed, the name "DateTime" means "the date/time type we want developers to try first if they don't know which type to pick." To avoid bugs like the last-call example above, all* surveyed platforms with a zoned date/time type DON'T offer an unzoned type named "DateTime" because they don't want naive users accidentally choosing the unzoned type by default. The (more opinionated) Rust and Elixir named their zoned type "DateTime" while the (less opinionated) Java doesn't have a type named "DateTime". My preference is to follow Elixir/Rust's pattern, but consensus was to be less opinionated like Java which I'm OK with. IMHO, the only really bad outcome would be to make the "default" name (aka DateTime) be zoneless.

* except the boost C++ library which probably has relatively little overlap with JS developers

[ljharb]

@justingrant hmm, why would the zone be ignored? i'd expect it to be an error if i try to provide a timezone to an unzoned type.

[stebogit]

Leaves open the option for third-party libraries, or a potential Temporal follow-up, to add ZonedDate and ZonedTime, which are both well-defined on their own.

@sffc what would be the purpose/use of a ZonedTime? Maybe, just guessing, a wall-clock that automatically updates with DST? But and how can you define such class if, by definition, it doesn't include a date (otherwise it would be a ZonedDateTime), which is what allows you to determine when to switch?

Same thing for ZonedDate, how is it different in behavior/results than a Date? If it had a timezone it would be a ZonedDateTime, wouldn't it?

[sffc]

Leaves open the option for third-party libraries, or a potential Temporal follow-up, to add ZonedDate and ZonedTime, which are both well-defined on their own.

@sffc what would be the purpose/use of a ZonedTime? Maybe, just guessing, a wall-clock that automatically updates with DST? But and how can you define such class if, by definition, it doesn't include a date (otherwise it would be a ZonedDateTime), which is what allows you to determine when to switch?

Same thing for ZonedDate, how is it different in behavior/results than a Date? If it had a timezone it would be a ZonedDateTime, wouldn't it?

@pipobscure can answer this better than me, but a ZonedDate is a span of time lasting a whole calendar day in a time zone, and a ZonedTime is an incomplete piece of information that makes sense once paired with a XxxxDate. For example, nationally broadcast primetime events in the United States typically begin at "9pm America/New_York", a ZonedTime.

The claim is not that these types are particularly useful. They aren't being proposed for inclusion in Temporal. However, they illustrate the difference in realms between types with time zones and types without time zones.

[stebogit]

@pipobscure can answer this better than me, but a ZonedDate is a span of time lasting a whole calendar day in a time zone

Isn't that though a "period" concept though, like somehow (arguably) similar to Duration? I mean, it's a different concept from a Date, which would imply a different name/class (say Period/ZonedPeriod). This just to confirm that to me a ZonedDate or ZoneTime still does not really make sense. 😅

[justingrant]

@justingrant hmm, why would the zone be ignored? i'd expect it to be an error if i try to provide a timezone to an unzoned type.

@ljharb JS usually doesn't complain if extra data is provided in a method call.

dt1 = Temporal.DateTime.from('2020-03-08T01:00-07:00[America/Los_Angeles]');
dt2 = Temporal.DateTime.from({ year: 2020, month: 3, day: 8, hour: 1, timeZone: 'America/Los_Angeles' });

Neither of the lines above throw an exception or provide any indication that there's a problem at development time or at runtime until the user tries to derive a new value (e.g. adding 2 hours) near a DST transition.

But the case above is the easy case. A harder case is when developers don't realize that a time zone is needed because they're not thinking of DST edge cases and what can go wrong. An even harder case is where developers know a timezone is needed and use a timezone, but they commit order-of-operations bugs like @ptomato did in #698. And he's an expert! The median developer is far worse and commits these kinds of bugs frequently.

With a zoned type these kinds of bugs are almost impossible to commit, because a time zone is required and DST best practices are baked in to the implementation. Once you've successfully created a ZonedDateTime (new name for LocalDateTime as of today), then you're guaranteed that subsequent derived values (e.g. with plus, minus, difference, with, etc.) will be created in a DST-safe way in the same time zone. This is the reason why most newer platforms have chosen to follow the lead of Joda Time which pioneered this "zoned type" approach about a decade ago.

[ljharb]

JS doesn't complain if unknown data is provided - however, the dateStyle/timeStyle precedent imo suggests that when known and incorrect data is provided, an exception is ideal and warranted. In this case, it seems like making the unzoned types throw when a timeZone is provided would address the usability concerns, since it'd be impossible to accidentally make an unzoned type when you wanted a zoned one, and if you don't want a zoned one, then the unzoned type is likely correct.

[mrjacobbloom]

Hey! Sorry to interrupt, but I don't think anyone's brought this up yet: I keep misreading "naive" as "native" (a word I see far more often day-to-day), which gives me the impression that the difference between these two types is that one is "native" (to the OS?) and the other one is... userland/3rd-party? Not sure whether this misreading is common or specific to me but I thought I'd mention it

[justingrant]

when known and incorrect data is provided, an exception is ideal and warranted.

@ljharb Currently, Temporal doesn't consider extra fields as "incorrect" because there are valid use cases for extracting partial data from an ISO string or property bag. One common example is when the same storage is shared among multiple consumers. For example, 2020-03-08T01:00-07:00[America/Los_Angeles] stored in a database column with three consumers:

• A reporting app only cares about the date
• A back-end microservice only cares about the instant
• A UI only cares about the human-readable date and time

Today all of those cases can call from on Date, Instant, and DateTime respectively without errors. Other use cases include handling mixed inputs (e.g. some have a date & time, some only a date) or migrating from one storage format to another without breaking clients. Another case we may support (see #933) is parsing formats with some components omitted, e.g. date+timezone, or date+time+timezone without offset. Another case is Calendar.from and TimeZone.from being able to parse the timezone (only) or calendar (only) from an extended ISO string like 2020-03-08T01:00-07:00[America/Los_Angeles][c=japanese].

it seems like making the unzoned types throw when a timeZone is provided would address the usability concerns, since it'd be impossible to accidentally make an unzoned type when you wanted a zoned one, and if you don't want a zoned one, then the unzoned type is likely correct.

We could make parsing stricter only for the time zone and only for the from and with methods of the unzoned type. This would be inconsistent but it would help the failure case you noted. But AFAIK that failure case is relatively unusual.

The harder and more common problem is that many developers won't know that they should be using the zoned type for many use cases, because DST-safe programming is confusing and the unzoned date/time type usually works OK in a dev environment or CI. Problems generally crop up only in production and only around DST transitions (or other time zone definition changes like when Brazil abruptly decided to stop using DST) which are intermittent, dependent on geography, and not usually covered by test automation.

This is why modern date/time APIs across multiple platforms generally avoid giving a "default-sounding" name ("DateTime") to the zoneless type, because a large % of developers won't intuitively expect to need a zoned type for many use cases. Cues from the names are helpful to guide novices to the correct type.

[ljharb]

I agree, and regardless of the names, some errors like we’ve discussed would ensure they immediately and always get an error pointing them in the right direction. That way, because no matter what names we pick, there will be confusion, the underlying problem is actually solved.

In other words, yes, the names should be descriptive, but the usability argument imo doesn’t apply to naming if we have good errors for these cases.

[pipobscure]

We had these discussions in detail. We very much considered different ways of handling these issues and came to this conclusion after very careful consideration.

While I’m happy to go through some of the reasoning, and it’s preserved in the minutes of meetings, I don’t think it’s particularly helpful do relitigate this here. Am I the only one of that opinion?

On Sat, 3 Oct 2020 at 00:25, Jordan Harband notifications@github.com wrote:

I agree, and regardless of the names, some errors like we’ve discussed would ensure they immediately and always get an error pointing them in the right direction. That way, because no matter what names we pick, there will be confusion, the underlying problem is actually solved.

In other words, yes, the names should be descriptive, but the usability argument imo doesn’t apply to naming if we have good errors for these cases.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-temporal/issues/707#issuecomment-702998615, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADM5L4X2NVGPS5QGTNTGF3SIZOOVANCNFSM4OI7RDCA .

[justingrant]

Hi @ljharb - There's a lot of back-n-forth so I want to make sure I understand your feedback. A few short questions to clarify:

1) You're suggesting that Temporal.DateTime.from should throw if a time zone is present in the input. Are you also suggesting that from of all Temporal types should throw if additional data is present beyond what that type can represent? (This change would break a bunch of use cases and/or make them more difficult.)

2) Are you supportive of excluding the unprefixed name "DateTime" from possible names for the unzoned date/time type, per discussion above about the problems of accidental use of the unzoned date/time type? If not, why not?

3) if (2) is "yes", then DateTime will have a prefix. We're currently looking at Naive, Plain, Floating, and Civil for those prefixes. I know you really don't like "Naive". Are there any other names on the shortlist that you think are so bad that you'd want to block even if it turns out that Twitter loves them?

4) if (2) is "yes", then DateTime will have a prefix. Are you OK with the same prefix on Date and Time per the team's consensus today?

5) Is there any other feedback that you've been trying to get across re: naming these date/time types that's not captured by the 4 questions/answers above?

[ljharb]

1. Only the unzoned types, and only if a timezone is provided.
2. I’d prefer no prefix at all.
3. If there is a prefix, I’d prefer Local, Plain, Civil, i suppose.
4. I also think it’s better if Date and Time are unprefixed, even if DateTime is prefixed.
5. I think the only thing that may not be coming across is that if 1 happens, i think the possible accidental use of an unzoned type stops being a problem, which means it doesn’t have to be part of the decision about a prefix.

[pipobscure]

@ljharb thanks for the feed back.

Given that we had this very discussion yesterds as well as last week, and after careful consideration reached conflicting conclusions, makes me think reading and following the arguments made may well lead you there as well. Can I invite you to read the minutes of these meetings and then come back to the discussion? I am also happy to sit down (virtually) with you and explain the rationales.

Until then, I don’t really know what to do based on that feedback. These things were considered and discussed at length and that was necessary for us to reach this consensus. Many of us started out at many different places including agreeing with you. So that I have to assume that actually following the reasoning would move your point of view into agreement with the decision as it stands now.

And that in turn would mean the right thing to do is to utterly ignore what you’re saying, which I’m not willing to do. So what would be a good process to engage here?

On Sat, 3 Oct 2020 at 02:13, Jordan Harband notifications@github.com wrote:

1. Only the unzoned types, and only if a timezone is provided.

2. I’d prefer no prefix at all.

3. If there is a prefix, I’d prefer Local, Plain, Civil, i suppose.

4. I also think it’s better if Date and Time are unprefixed, even if DateTime is prefixed.

5. I think the only thing that may not be coming across is that if 1 happens, i think the possible accidental use of an unzoned type stops being a problem, which means it doesn’t have to be part of the decision about a prefix.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-temporal/issues/707#issuecomment-703020597, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADM5L3UBNVIETBIE7QPL53SIZ3CRANCNFSM4OI7RDCA .

[gilmoreorless]

Finally catching up after the usual weekly flurry of comments in this repo. Excuse the haphazard replies to different comments. 😄

Python does have the ability for the datetime type to use time zones, but there's no built-in IANA support. You'd need a 3rd-party library for that.

Extra data point for completeness — that's no longer true as of Python 3.9: https://www.python.org/dev/peps/pep-0615/

(P.S.: despite feedback, I am still of the opinion that clarity trumps brevity 100% of the time)

I am definitely on @pipobscure's side here. I get the brevity argument, and it is important, but IMO it's not as important as being consistent.

Given that we had this very discussion yesterds as well as last week, and after careful consideration reached conflicting conclusions, makes me think reading and following the arguments made may well lead you there as well. Can I invite you to read the minutes of these meetings and then come back to the discussion?

@pipobscure I know your reply was to @ljharb, but are those meeting notes available for anyone else to see as well? There are plenty of non-TC39 people who have commented on this issue, who might be interested in the arguments that were made. The meeting notes section of the repo hasn't had any new content in months.

[ryzokuken]

The meeting notes section of the repo hasn't had any new content in months.

I was thinking about this as well, I'll update it later today.

[ryzokuken]

Notes PR up at #959

[justingrant]

Notes PR up at #959

Thanks @ryzokuken! The minutes with this discussion are here: https://github.com/tc39/proposal-temporal/blob/869bdc253ce35ba85166c913168f2dd8136fe356/meetings/agenda-minutes-2020-10-01.md Look for the heading "What should be the long-term name of LocalDateTime ? (continued)"

Extra data point for completeness — that's no longer true as of Python 3.9: https://www.python.org/dev/peps/pep-0615/

@gilmoreorless - thanks! I updated the table.

I am definitely on @pipobscure's side here. I get the brevity argument, and it is important, but IMO it's not as important as being consistent.

AFAIK there's universal agreement on this point. The only question in the meeting was which consistency is more important? Consistency between the two date/time types, or consistency between the unzoned date/time type, the date type, and the time type. In other words, if I have a date and want to add a time to it, should the names encourage me to convert it to a zoneless date/time, a zoned date/time, or should neither be preferred by the names?

The consensus was that consistency between the unzoned date/time type and date and time types was more important.

I disagreed (I expect most users to view the two date/time types as closer to each other than to Date or Time, and that naming should never encourage use of the zoneless type) but also didn't think this was worth blocking consensus.

The only consensus-blocking opinion I have is that the zoneless name should NOT be DateTime, because it'd encourage novices to choose the unzoned date/time type because in almost every other platform the word "DateTime" refers to the date/time type that's preferred for novices to try first. It's probably not an accident that in almost all platforms with an IANA zoned type, the word "DateTime" either refers to the zoned type or is not used at all.

[gilmoreorless]

Thanks for adding the notes, @ryzokuken!

AFAIK there's universal agreement on this point. The only question in the meeting was which consistency is more important? Consistency between the two date/time types, or consistency between the unzoned date/time type, the date type, and the time type. In other words, if I have a date and want to add a time to it, should the names encourage me to convert it to a zoneless date/time, a zoned date/time, or should neither be preferred by the names?

The consensus was that consistency between the unzoned date/time type and date and time types was more important.

I agree with this. Looking more abstractly, if there are two classes ThingA and ThingB, and you can add them together into a combined class, I would definitely expect the combined class to follow the same naming pattern (such as ThingAB).

[dvberzon]

I would be wary of using ZonedDateTime to mean a date time with a zone.

'zone' as a verb has two common meanings, either 'to split into different areas', as in 'the park has been zoned into four distinct bioregions, each with its own ecological identity', or 'designate (a specific area) for use or development as a particular zone in planning' as in 'the land is zoned for housing'.

The date time in question has not been 'zoned'. It has a timezone.

On Mon, 5 Oct 2020, 12:31 Gilmore Davidson, notifications@github.com wrote:

Thanks for adding the notes, @ryzokuken https://github.com/ryzokuken!

AFAIK there's universal agreement on this point. The only question in the meeting was which consistency is more important? Consistency between the two date/time types, or consistency between the unzoned date/time type, the date type, and the time type. In other words, if I have a date and want to add a time to it, should the names encourage me to convert it to a zoneless date/time, a zoned date/time, or should neither be preferred by the names?

The consensus was that consistency between the unzoned date/time type and date and time types was more important.

I agree with this. Looking more abstractly, if there are two classes ThingA and ThingB, and you can add them together into a combined class, I would definitely expect the combined class to follow the same naming pattern (such as ThingAB).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-temporal/issues/707#issuecomment-703572971, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGFWOVJO2Z5LM3IKD4QCLMLSJGVBJANCNFSM4OI7RDCA .

[ryzokuken]

@dvberzon

'zone' as a verb has two common meanings, either 'to split into different areas', as in 'the park has been zoned into four distinct bioregions, each with its own ecological identity', or 'designate (a specific area) for use or development as a particular zone in planning' as in 'the land is zoned for housing'.

While this is the correct meaning of the word "zoned" in the context of urban planning, this definition does not (and cannot possibly) apply to dates and times in JavaScript. In the case of JavaScript, zoned would instead have a different connotation, likely one linked to https://github.com/domenic/zones.

In the case of Temporal, however, the definition "containing a timezone" is more accurate than either of these.

[pipobscure]

And aside from that: a TimeZone IS an area of the world split of from the whole. Whence the passive voice “zoned”. Interestingly enough this is so similar with parks and housing, which might be why they are called timezones. Additionally similarly to how development areas are called “zoned” and parks are “zoned” the time of the world is also “zoned”.

On Mon, 5 Oct 2020 at 16:14, Ujjwal Sharma notifications@github.com wrote:

@dvberzon https://github.com/dvberzon

'zone' as a verb has two common meanings, either 'to split into different

areas', as in

'the park has been zoned into four distinct bioregions, each with its own

ecological identity', or 'designate (a specific area) for use or

development as a particular zone in planning' as in 'the land is zoned for

housing'.

While this is the correct meaning of the word "zoned" in the context of urban planning, this definition does not (and cannot possibly) apply to dates and times in JavaScript. In the case of JavaScript, zoned would instead have a different connotation, likely one linked to https://github.com/domenic/zones.

In the case of Temporal, however, the definition "containing a timezone" is more accurate than either of these.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-temporal/issues/707#issuecomment-703698108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADM5L3532IPFENZUQH3FP3SJHPELANCNFSM4OI7RDCA .

[justingrant]

Meeting 2020-10-08: Choices to poll are Plain, Civil, and Floating, and "Other (please reply)".

[dvberzon]

There are a few examples in English of taking a noun and turning it into a verb participle to indicate possession.

For example a person with money can (a bit archaically) be called “A moneyed person”

But you almost never do that in English with a noun that is already a verb.

For example you wouldn’t call a "result that included information about a doctor" a “doctored result”. People would immediately think that meant a result that had been tampered with.

Or a house that has a drive a “Driven house”. That’s just nonsense.

As a native English speaker I would find it hard to imagine describing something as Zoned to mean something that possessed a zone.

I’m much more likely to go with the more common interpretation of either being split into zones or having been designated a zone.

I’m just pointing this out because ZonedDateTime does not to my ears sound like a description of a date time that includes a time zone.

On 5 Oct 2020, at 16:14, Ujjwal Sharma notifications@github.com wrote:

@dvberzon https://github.com/dvberzon 'zone' as a verb has two common meanings, either 'to split into different areas', as in 'the park has been zoned into four distinct bioregions, each with its own ecological identity', or 'designate (a specific area) for use or development as a particular zone in planning' as in 'the land is zoned for housing'.

While this is the correct meaning of the word "zoned" in the context of urban planning, this definition does not (and cannot possibly) apply to dates and times in JavaScript. In the case of JavaScript, zoned would instead have a different connotation, likely one linked to https://github.com/domenic/zones https://github.com/domenic/zones.

In the case of Temporal, however, the definition "containing a timezone" is more accurate than either of these.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-temporal/issues/707#issuecomment-703698108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGFWOVMPQTVYL323EQRWX63SJHPENANCNFSM4OI7RDCA.

[pipobscure]

Thanks, because that’s exactly what this describes: a DateTime “having been designated a zone”

On Thu, 8 Oct 2020 at 17:41, Daniel van Berzon notifications@github.com wrote:

There are a few examples in English of taking a noun and turning it into a verb participle to indicate possession.

For example a person with money can (a bit archaically) be called “A moneyed person”

But you almost never do that in English with a noun that is already a verb.

For example you wouldn’t call a "result that included information about a doctor" a “doctored result”. People would immediately think that meant a result that had been tampered with.

Or a house that has a drive a “Driven house”. That’s just nonsense.

As a native English speaker I would find it hard to imagine describing something as Zoned to mean something that possessed a zone.

I’m much more likely to go with the more common interpretation of either being split into zones or having been designated a zone.

I’m just pointing this out because ZonedDateTime does not to my ears sound like a description of a date time that includes a time zone.

On 5 Oct 2020, at 16:14, Ujjwal Sharma notifications@github.com wrote:

@dvberzon https://github.com/dvberzon 'zone' as a verb has two common meanings, either 'to split into different areas', as in 'the park has been zoned into four distinct bioregions, each with its own ecological identity', or 'designate (a specific area) for use or development as a particular zone in planning' as in 'the land is zoned for housing'.

While this is the correct meaning of the word "zoned" in the context of urban planning, this definition does not (and cannot possibly) apply to dates and times in JavaScript. In the case of JavaScript, zoned would instead have a different connotation, likely one linked to https://github.com/domenic/zones https://github.com/domenic/zones.

In the case of Temporal, however, the definition "containing a timezone" is more accurate than either of these.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/tc39/proposal-temporal/issues/707#issuecomment-703698108>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AGFWOVMPQTVYL323EQRWX63SJHPENANCNFSM4OI7RDCA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-temporal/issues/707#issuecomment-705690478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADM5L7V36KMJ3RMSJSAAP3SJXTULANCNFSM4OI7RDCA .

[justingrant]

FYI: while browsing the iCalendar spec (https://tools.ietf.org/html/rfc5545#section-3.3.5) for another reason, I noticed that it uses the adjective "floating" to describe unzoned date/time values:

FORM #1: DATE WITH LOCAL TIME

  The date with local time form is simply a DATE-TIME value that
  does not contain the UTC designator nor does it reference a time
  zone.  For example, the following represents January 18, 1998, at
  11 PM:

   19980118T230000

  DATE-TIME values of this type are said to be "floating" and are
  not bound to any time zone in particular.  They are used to
  represent the same hour, minute, and second value regardless of
  which time zone is currently being observed.

[justingrant]

Twitter poll results after almost 2 days:

[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.