-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bikeshedding the names of the static methods to get current date/time/etc #236
Comments
/cc @pipobscure |
I have no passion either way. I’d also be fine to reduce them two just two; Temporal.here() // current TimeZone |
Resolution: ?
|
I like maybe?
|
Not sure why there is getTimeZone rather than getCurrentTimeZone above. |
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) |
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) |
Ok, from this thread and mentions on other threads I think the conclusion is:
Questions:
(I'd like to close this out and implement it; which is why I'm looking for an answer.) |
Personally, yes, I think we should. |
@sffc I'm a bit in favor of not having those (since they're just one method call away from |
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. |
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. |
I see that these are called
getAbsolute()
,getYearMonth()
,getTimeZone()
, etc. A couple issues with these names: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 objectTemporal.current
!I have to say, I'm not very excited about these options either... does anyone else have any ideas?
The text was updated successfully, but these errors were encountered: