[ruby-core:110469] [Ruby master Feature#19071] Add Time#deconstruct, #deconstruct_keys, and #to_h

["sawa (Tsuyoshi Sawada)" <noreply@ruby-lang.org>]

Issue #19071 has been updated by sawa (Tsuyoshi Sawada).


@duerst (Martin Dürst), @zverok (Victor Shepelev)
In short, I think you two misinterpreted my comment. I never wrote that the order of the units is wrong. I am talking about the combination of the units.

--

duerst (Martin Dürst) wrote in #note-4:
> it's very clearly ordered from larger units to smaller, and this is a very widely used convention not only for time, but also for other units including currencies. Also, it's the order used in ISO 8601, the international standard for date and time formats. So very far from arbitrary.

I am not sure why you are mentioning the order. If that combination `[year, month, mday, hour, min, sec, subsec] ` were to be used, sure, ordering from larger units to smaller like that is the most logical way. No question. You mentioned currencies, but in Japanese, as you may know, that is the way it works for anything from family name-first name order, addresses, etc. In Japanese, even the AM/PM (午前/午後) is read after the day but before the hour because they (having half day span) are smaller units than a day but larger than hours.

zverok (Victor Shepelev) wrote in #note-5:
> I don't think this statement is fair. This sequence of units is not natural for some particular culture. E.g. 18:10 at Oct 21 would be written "10/21/22 6:10pm" in US, and "18:10 21.10.2022" in Ukraine, but `"2022-10-21 18:10:00"` is rather a common engineering implementation, logically structured for unambiguous parsing and sorting. 

What is not fair? Of course `"2022-10-21 18:10:00"` is more logical and easier to parse than "18:10 at Oct 21", "10/21/22 6:10pm" or "18:10 21.10.2022". What is the point of bringing up somewhat convoluted formats and comparing with them?

duerst (Martin Dürst) wrote in #note-4:
> There may be such people (I know that week number/weekday is very popular in Germany for business meetings), but overall this is a very small minority, and virtually everybody is familiar with (western) months.

I did not say that people are not familiar with months. The concept is so wide spread that many people know it. The question is, whether they want to (be force to) use it in their code.

zverok (Victor Shepelev) wrote in #note-5:
> I understand there are different cultures out there (and for some, it is not "Oct 21, 2022" at all, but maybe "26 Tishrei, 5783" or "25 Rabi ul Awal 1444", or something else), but I believe it can be said with a high confidence that 
> 1. when seeing a sequence of numbers starting with `2022,` or `year,`, most of **developers** can guess the forthcoming units.
> 2. when trying to design or guess sequence of units of Time/Date representation _today_ (with widespread standardization, JSON serializations etc.), the best guess would be close to ISO8601 Date & Time format.

The very ISO8601 that you mention disallows commonplace descriptors of dates (or parts of dates) like "January", "Thursday", or "New Year's Day". So the formats you mention: "Oct 21, 2022", "26 Tishrei, 5783", or "25 Rabi ul Awal 1444" are all out of question.

And the  very ISO8601 that you mention does not force you to use calendar dates (month-based dates). It equally specifies week dates (week-based dates) and ordinal dates (dates based on the day of the year) as well.

I do not understand the point of your statement:

> 1. when seeing a sequence of numbers starting with `2022,` or `year,`, most of **developers** can guess the forthcoming units.

Sure, given the ISO 8601 format "2022-294", we can tell it is the 294th day of year 2022, or given the ISO 8601 format "2009-W53-7", we can tell that it is the Sunday of 53rd week of year 2009. What is wrong with that? And how is that related to my comment?

----------------------------------------
Feature #19071: Add Time#deconstruct, #deconstruct_keys, and #to_h
https://bugs.ruby-lang.org/issues/19071#change-99788

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
----------------------------------------
I believe that `Time` being suitable for pattern-matching is a reasonable feature with many possible usages, which will increase usability of `Time` and would be a good show case for pattern matching.

**Implementation decisions**

`Time#deconstruct`: 
* returns time components in order `[year, month, mday, hour, min, sec, subsec]`
* I believe the highest-to-lowest order is the only reasonable/guessable, and there is no point to put into the array _all_ of the time information available (e.g. zone, wday, yday)
* I am not sure (and open to discussion) about `subsec`. It seems to me the most basic sub-second unit of Time, but I might be wrong; also, it might be not that useful for array deconstruction.

Possible usage:
```ruby
case tm
in [...2022, *]
  puts "previous year"
in [2022, 1..6, *]
  puts "Q1-2"
in [2022, 7..9, *]
  puts "Q3"
in [2022, month, day, *]
  puts "Current quarter, #{day}/#{month}"
end
```

`Time#deconstruct_keys`: 
* chosen keys: `[:year, :month, :day, :yday, :wday, :hour, :min, :sec, :subsec, :dst, :zone]` 
* I am open to discussing whether we should include other subsecond units (or any whatsoever)
* It might be useful (but too loose interface) to support `mon` as a synonym for `month`?.. But might be confusing if somebody will unpack the `**rest`
* `day`, not `mday`, seems most reasonable

Possible usages:
```ruby
case t
in year: ...2022
  puts "too old"
in month: ..9
  puts "quarter 1-3"
in wday: 1..5, month:
  puts "working day in month #{month}"
end

if t in Time(wday: 3, day: ..7)
  puts "first Wednesday of the month"
end
```

`Time#to_h`:
* added on a "why not" basis :) As we already have "convert to hash" in the form of `deconstruct_keys(nil)`, having a canonic form seems harmles. Open for discussion.
* keys are the same as for `deconstruct_keys`

Pull request: https://github.com/ruby/ruby/pull/6594



-- 
https://bugs.ruby-lang.org/