Proposal-temporal: Bikeshedding the names of the static methods to get current date/time/etc

[littledan]

I see that these are called getAbsolute(), getYearMonth(), getTimeZone(), etc. A couple issues with these names:

• They match the names of the projection methods while doing something completely different (though maybe we should get rid of these anyway #233)
• Subjectively, to me, they don't really seem to imply anything about how they refer to the here and now. We're getting an Absolute, but which one?

Some options that come to mind:

• Temporal.getCurrentAbsolute() -- current is already everyone's favorite meaningless variable name when you can't think of anything, so it'd be a great fit for this bikeshed!
• Temporal.now.getAbsolute() -- grouping it on a singleton object which represents "now" could make it more explicit (since the Temporal namespace doesn't really indicate that). We could even call this singleton object Temporal.current!

I have to say, I'm not very excited about these options either... does anyone else have any ideas?

[ryzokuken]

/cc @pipobscure

[pipobscure]

I have no passion either way. I’d also be fine to reduce them two just two;

Temporal.here() // current TimeZone
Temporal.now() // current Absolute

[pipobscure]

Resolution: ?

Temporal.getCurrentDateTime()
Temporal.getCurrentAbsolute()
Temporal.getTimeZone()

[sffc]

I like maybe?

Temporal.now.absolute()
Temporal.now.timeZone()
Temporal.now.dateTime()

[littledan]

Not sure why there is getTimeZone rather than getCurrentTimeZone above.

[pipobscure]

Is the Timezone ever NOT current? What does “current” add to the meaning?

(Any justification will do, I was just thinking that the TZ is not ever going to be non-current; in contrast with an Absolute that would change every 10e-9 seconds)

[littledan]

Well, for example, a compound ZonedDateTime might have a way to project out a time zone, but it wouldn't be the current one. (I agree that "current" is bad; personally, I prefer @sffc's suggestion above)

[pipobscure]

Ok, from this thread and mentions on other threads I think the conclusion is:

• Temporal.now.absolute()
• Temporal.now.dateTime()
• Temporal.now.timeZone()

Questions:

1. should we add Temporal.now.date() and Temporal.now.time() as well?
2. is the assessment that this is the right conclusion from the discussion correct?

(I'd like to close this out and implement it; which is why I'm looking for an answer.)

[sffc]

should we add Temporal.now.date() and Temporal.now.time() as well?

Personally, yes, I think we should.

[ryzokuken]

@sffc I'm a bit in favor of not having those (since they're just one method call away from DateTime). Would you mind sharing why you think we should have them?

[sffc]

Having separate methods is a bit shorter, but the main advantage is that it could open up performance gains. For example, computing the year/month/day might be more expensive than computing the hour/minute/second (or vice-versa), and having to detour through DateTime requires creating an extra object. This is a theoretical concern for which I have no data.

[ryzokuken]

Okay, I understand your concern. I usually try to advocate for avoiding things which we absolutely need, but given your concern, I don't have a strong preference here.