Temporal.Date vs "Classic" Date ?

[justingrant]

What are the implications of Temporal.Date sharing a name with classic JS Date?

Will devs have to import . . . from temporal, and if so will import { Date } from 'temporal' break all previously-working uses of classic JS Date in the same module?

Regardless, should temporal.Date be called something else (e.g. DateOnly) to remove this ambiguity? I assume that this change might also imply changes to Time, MonthDay, and YearMonth.

[ljharb]

You can rename anything while importing, so if you need to use both, you have a pretty easy solution.

[ptomato]

Temporal won't be a module (that was considered at one point, but IIUC it didn't seem like a good idea to make this proposal depend on built-in modules). Instead it's a globally available object (like Math). So by default it'll always be Temporal.Date. You can still do const { Date } = Temporal if you want the short form and don't mind shadowing Date, but that's entirely opt-in.

[justingrant]

@ptomato - Got it, makes sense. Sounds like name conflicts in user code would be unusual. I still think it's a little unusual to have two built-in classes sharing the same name because logging or debugging code often has a default display for objects which uses constructor.name which would be Date for both classes.

Can (and if yes, should) Temporal to override (with Object.setProperty) set constructor.name to Temporal.Date which would prevent this problem? The section in MDN about changing class constructor names is IMHO confusing, so I think it's possible to rename constructor.name, but not 100% sure what the limitations are. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name#Function_names_in_classes

[justingrant]

I found another problem case in #562. Every time anyone writes Date in documentation, in a GH issue, in email, etc. you won't know which Date is being referred to.

For example, how will Temporal's own documentation distinguish between the two? Will every reference to Date in the docs be prefixed with Temporal.? If not, how will readers know which one you're referring to? And how will users know that Date refers to globalThis.Date? Will those references get a prefix too in the docs?

[ptomato]

We do specify that [Symbol.toStringTag] is "Temporal.Date" (https://tc39.es/proposal-temporal/#sec-temporal.date.prototype-@@tostringtag) which produces ... varyingly useful results depending on which console environment you're in:

• Node.js: Date [Temporal.Date] {}
• Firefox 75: Object { }
• Chromium 81: T {}

In the Temporal documentation we are referring consistently to "Temporal.Date" and "legacy Date" but you're right this is a problem everywhere else outside the Temporal documentation.

[ljharb]

Both .constructor, and .name, are unreliable detection mechanisms anyways, so I don't think there's any point in changing them.

Yes, Temporal.X is how I expect every X in Temporal to be described in all documentation.

[justingrant]

Unreliable or not, logging & debuggers needs to show something-- and if that something ends up being Date, then it will be confusing for at least some users. Having a name that doesn't overlap with a built-in object would make things easier.

FWIW, we faced exactly this problem at my last company and we ended up naming types DateTime, DateOnly, TimeOnly, etc. Anything that was a subset of another type got the Only prefix. YMMV, but it worked well for our team.

[ljharb]

You won't be logging the constructors tho, you'll be logging the instances, where the Symbol.toStringTag (with the Temporal. prefix) will be shown - so i don't think the problem you're concerned about actually will occur.

[littledan]

I agree with others here that, part of the idea of settling on the Temporal.Date name was that we'd always refer to it as Temporal.Date and never as Date.

We had a very lengthy discussion on the name of these classes, earlier in this repository, see #33

[ptomato]

I added better debug output some time ago, I think all the concerns are addressed and we can close this? Feel free to reopen if there's still something we should discuss.

[justingrant]

One possible open issue is what we should call the existing "Date" type in Temporal docs and in other official places. Whatever we call it will (probably? hopefully?) be picked up by the wider community, assuming we pick the right phrase.

Have we done any bikeshedding on what to call the old Date? If not, should we?

I assume that the default answer is "legacy Date" which I'd be OK with, but I also wonder if there's a better phrase. I'm also not sure if "legacy" has connotations in some (spoken, not computer) languages that we'd want to avoid.

Also, has this come up elsewhere in JS? Are there JS features that have deprecated older JS features?

[ptomato]

We did some bikeshedding on that topic in March or April or so, and settled on consistently calling it "legacy Date".

There aren't any other such features that I can think of! There's with which was made obsolete by object spreading, but they aren't named the same. There are plenty of JS features which have made userland polyfills obsolete, even ones of the same name, but that's not the same either because it's generally clear from the context whether you are referring to the JS feature or the userland one.

[justingrant]

Sounds good. At some point (later!) it may be worth a scrub through the docs to make sure that we're calling it "legacy Date" consistently.