Feature #10040
closed`%d` and `%t` shorthands for `Date.new(*args)` and `Time.new(*args)`
Description
I'm working on a Ruby application where we have to deal with a lot of dates and times, especially in our test suite. We currently have a couple thousand cases of Date.new(...)
, and I'm finding the syntax to be a little unwieldy.
What do you think about the following shorthand suggestions?
%d(2014, 7, 15) # Equivalent to: Date.new(2014, 7, 15)
%t(2014, 7, 15, 12, 58, 45) # Equivalent to: Time.new(2014, 7, 15, 12, 58, 45)
I added commas because I think the syntax should also support variables:
year = 2014
month = 7
%d(year, month, 15) # Equivalent to: Date.new(year, month, 15)
I understand that this will operate a bit differently to %w
and %i
, but I think that supporting variable evaluation would be a lot more useful.
An alternative proposal would be to add []
methods to Date
and Time
, so that we could call:
Date[2014, 7, 15]
Time[2014, 7, 15, 12, 58, 43]
This would be still be a little shorter and nicer to use. Please let me know if you would like me to open a feature ticket for Date.[]
and Time.[]
methods, instead.
Please let me know your thoughts. Would you find a shorter date/time syntax useful?
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
- Description updated (diff)
I don't think there is possibilities to introduce %d
and %i
, especially using variables.
But the latter would be different story, you may want to file another ticket for it.
And yet another idea came to my mind:
20140715T125845 #=> Time.new(2014, 7, 15, 12, 58, 45)
20140715T125845Z #=> Time.new(2014, 7, 15, 12, 58, 45, "+00:00")
990715T125845 #=> Time.new(99, 7, 15, 12, 58, 45); 1st century, not 19th century
20140715T125845.001.subsec #=> 1/100
Updated by nathan.f77 (Nathan Broadbent) about 10 years ago
Nobuyoshi Nakada wrote:
I don't think there is possibilities to introduce
%d
and%i
, especially using variables.
I understand if the syntax doesn't feel quite right, I'm not sure about it either. But I think it should be quite a simple patch, since we would just need to replace any %d
tokens with Date.new
, before evaluating it.
And yet another idea came to my mind:
20140715T125845 #=> Time.new(2014, 7, 15, 12, 58, 45) 20140715T125845Z #=> Time.new(2014, 7, 15, 12, 58, 45, "+00:00") 990715T125845 #=> Time.new(99, 7, 15, 12, 58, 45); 1st century, not 19th century 20140715T125845.001.subsec #=> 1/100
That would be amazing, I really like it. Do you have a suggestion for a Date
version, without the timestamp? How about: 20140715D
?
Updated by avit (Andrew Vit) about 10 years ago
I like that literal syntax!
Time.new(2014, 7, 15, 12, 58, 45, "+00:00").utc? #=> false
Time.utc(2014, 7, 15, 12, 58, 45).utc? #=> true
The "Z" suffix is for "Zulu Time", also known as UTC, so I would expect that to return a proper UTC time.
Nathan, Date is only available in stdlib (maybe it should be moved to core) so I don't think those literals will work for dates with "D".
One possibility:
20140715T == 20140715T000000
20140715TZ == 20140715T000000Z
20140715T.to_date
Updated by nathan.f77 (Nathan Broadbent) about 10 years ago
Nathan, Date is only available in stdlib (maybe it should be moved to core) so I don't think those literals will work for dates with "D".
I would definitely vote to move Date to core, I think that's a great idea
One possibility:
20140715T == 20140715T000000 20140715TZ == 20140715T000000Z 20140715T.to_date
Yep, I think 20140715T
or 20140715T.to_date
could be really useful.
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
Andrew Vit wrote:
The "Z" suffix is for "Zulu Time", also known as UTC, so I would expect that to return a proper UTC time.
Indeed.
Updated by matz (Yukihiro Matsumoto) about 10 years ago
- Status changed from Open to Feedback
I don't really understand the benefit of having Time literals.
I don't see 20140718T
more readable than Time.new(2014,7,18)
.
Matz.
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
Isn't 2014_07_18T10_20_30
better than it?
Updated by avit (Andrew Vit) about 10 years ago
It reads nicely, but these literals could only build Time constants without variables/interpolation, which are rarely needed (in my own experience).
I do use Time with constant values in test scenarios, but outside of that very rarely. Is it worth adding this for constants only?
Related: #8807
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
Time.[]
is better?
class Class
alias [] new
end
Time[2014, 7, 20, 12, 42, 24]