Feature #10040: `%d` and `%t` shorthands for `Date.new(*args)` and `Time.new(*args)`

• Status: Feedback
• Assignee: -
• Target version: -

[nathan.f77 (Nathan Broadbent)]

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?

[nobu (Nobuyoshi Nakada)]

• 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

[nathan.f77 (Nathan Broadbent)]

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?

[avit (Andrew Vit)]

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

[nathan.f77 (Nathan Broadbent)]

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.

[nobu (Nobuyoshi Nakada)]

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.

https://github.com/nobu/ruby/compare/time_literal

[matz (Yukihiro Matsumoto)]

• 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.

[nobu (Nobuyoshi Nakada)]

Isn't 2014_07_18T10_20_30 better than it?

[avit (Andrew Vit)]

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

[nobu (Nobuyoshi Nakada)]

Time.[] is better?

class Class
  alias [] new
end
Time[2014, 7, 20, 12, 42, 24]