I'm 👍 for this, since it's essentially an alias. Returning a tuple of year month day would be better.

I re-added the method returning a tuple. That's actually the best solution and at least an improvement for #5389

Why bother? Why would a tuple be preferable to a Time instance? Let's just drop the #date method.

Yeah fair enough, people can just do {time.year, time.month, time.day} to get the same thing.

This is faster than {time.year, time.month, time.day} because the calendar calculations don't need to be repeated (see #5389) and year_month_day_day_year is not publicly accessible. Go has time.Date and Python datetime.timetuple() which do the same thing (return a tuple).

IMHO it makes sense to have it but I'm also okay with removing the method entirely. At least it should not return a Time.

@ysbaddaden @RX14 WDYT about the performance implication? I'd suggest it's worth having this method.

The first thing to do when talking about performance is to benchmark it.

Fair enough:

TIME = Time.now

Benchmark.ips do |bm|
  bm.report("Time.date") { TIME.date }
  bm.report("{time.year, time.month, time.day}") { {TIME.year, TIME.month, TIME.day} }
end

                        Time.date   8.11M (123.33ns) (± 6.54%)  0 B/op        fastest
{time.year, time.month, time.day}   2.58M (387.84ns) (± 8.96%)  0 B/op   3.14× slower

As expected, {time.year, time.month, time.day} is about 3 times slower because it executes the same calendar operations for each date field.

Damn, year_month_day_day_year is a slow method...

Sure, let's go for this then.

Well, I'm running the specs in a VM on an old laptop. So the overall speed isn't as bad as it looks when running on reasonable hardware. 😀

Fair enough:

                        Time.date  28.55M ( 35.02ns) (± 7.36%)       fastest
{time.year, time.month, time.day}    9.7M (103.07ns) (± 7.51%)  2.94× slower

on my laptop.

Still actually 3 times slower.

I'm fine with renaming the method, though there are several options to consider:

• date -> as before but with different return type
• date_parts
• date_tuple (analog to Python's timetuple)
• to_date

Overall, I'd still prefer date over the alternatives. It's short and precise and I don't see a need to add some description of the returned type. See also #5389 for this; I think it would make sense to have date and clock return the date and clock fields, respectively, similar to Go's.

I think I lean towards date_parts personally. No named tuple.

Ping 🏓

Another approval, please?

Merge?

It's a breaking change, we have to wait until 0.28.0 is the next release. That's why I milestoned it.

Rebased and ready to ship.