From: "zverok (Victor Shepelev)" Date: 2022-10-22T13:08:43+00:00 Subject: [ruby-core:110477] [Ruby master Feature#19071] Add Time#deconstruct, #deconstruct_keys, and #to_h Issue #19071 has been updated by zverok (Victor Shepelev). @sawa With all due respect, I fail to see your point. For all I know: * most modern common serialization formats are using specifically "ISO8601 date and time" (which I specifically pointed at, NOT "everything ISO8601 is able to standardize") or something similar/compatible; even if they don't (RFC 2822, say), it is still based on day, month, year scheme, not week number or year day number (BTW, Ruby's `Time#iso8601`/`.iso8601` don't support `'2022-W42-6'` and `'2022-295'` and I fail to remember any complaints about that in the last years) * most of the time, Rubyists initiate new Time values with `Time.new(year, month, day, ...)` protocol, not with weeks or years. It is closest we have to time literal. So the idea of `deconstruct` was to be symmetrical to this, in the first place; * as far as I can guess, the other languages do the same: in Python it would be `datetime.datetime(2022, 10, 22, ...)`, in Java some `LocalDate.of(2022, 10, 22)`, etc. So, my point is: 1. There _are_ many possible representations and ways of construction of time and datetime objects, and we all are well aware of it; 2. Colloquially, though, the "day, month, and year" is the most widely known to developers, and `Y-m-d-H-M-S` (save for timezones and punctuation) is the most expected engineering representation In light of this, it would be hard for me to believe that there is any significant amount of engineers who would see in a generic code a sequence of numbers starting with year and would be stuck with guessing what the next number means. Do you have real cases in mind of communities/codebases for which "year-week" or "year-yday" are _the first representation that comes to mind_ while writing code? I am very curious to extend my understanding of the world if it is so. Or was your point just to put me in my place, as it needs to be done when somebody proposes too much stuff? I am OK with this, too, but would prefer it to be spelled explicitly. ---------------------------------------- Feature #19071: Add Time#deconstruct, #deconstruct_keys, and #to_h https://bugs.ruby-lang.org/issues/19071#change-99795 * 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/ Unsubscribe: