Every time (no pun intended) I want to get the current time I write Time.now. Then after getting an error I remember we changed it to Time.local.
I think Time.now is good: when you walk down the street and ask someone "what time is it now?" and they say "3 pm", I would be surprised if that means "3 pm UTC" or any other thing than the current local time.
In Go it's called time.Now(). In Python it's called datetime.datetime.now(). In Ruby it's Time.now. In Nim it's called now().
Could we bring it back? We can keep it as an alias of local in cases where one would think local is a bit more explicit, specially when using both local and utc to make it more obvious. I know we are against aliases, but this is just a tiny one. Otherwise we can remove local, but I don't see a need for that.
For reference, previous discussions in: #5346, #7586
This proposal would be in line with https://github.com/crystal-lang/crystal/pull/7586#issuecomment-476178139 f.
Time.now is confusing. Which timezone - UTC or local one?
Not having this method forces us to think to the above question.
If I ask time to someone not in my country, it will respond by precising the timezone.
That's why in the military, they use 24-hour format and precise the timezone, to remove any possible confusions.
I also prefer reading Time.local for local time, rather than Time.now for "now time" :)
Not having this method forces us to think to the above question.
That was exactly the reason for renaming Time.now to Time.local. To make it obvious that you consider what you want. Computer systems are not like people on the street which have an unanimous agreement that current time is most usefully expressed in the locally observed time zone.
Thus, adding Time.now back would counter that intention.
However, I wouldn't want to enforce an API that's hated by many users just in order to educate them.
@asterite You're only referring to methods without arguments, so I take you only mean to add the Time.now overload returning the current time, not the ones that construct a specified Time instance?
Well, nevermind.
Most helpful comment
That was exactly the reason for renaming
Time.nowtoTime.local. To make it obvious that you consider what you want. Computer systems are not like people on the street which have an unanimous agreement that current time is most usefully expressed in the locally observed time zone.Thus, adding
Time.nowback would counter that intention.However, I wouldn't want to enforce an API that's hated by many users just in order to educate them.
@asterite You're only referring to methods without arguments, so I take you only mean to add the
Time.nowoverload returning the current time, not the ones that construct a specifiedTimeinstance?