4 Commits

Author	SHA1	Message	Date
Loïc Riegel	5c59611083	feat: duration from record (#15600) ... Closes #15543 # Description 1. Simplify code in ``datetime.rs`` based on a suggestion in my last PR on "datetime from record" 1. Make ``into duration`` work with durations inside a record, provided as a cell path 1. Make ``into duration`` work with durations as record # User-Facing Changes ```nushell # Happy paths ~> {d: '1hr'} | into duration d ╭───┬─────╮ │ d │ 1hr │ ╰───┴─────╯ ~> {week: 10, day: 2, sign: '+'} | into duration 10wk 2day # Error paths and invalid usage ~> {week: 10, day: 2, sign: 'x'} | into duration Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #4:1:26] 1 │ {week: 10, day: 2, sign: 'x'} | into duration · ─┬─ ──────┬────── · │ ╰── encountered here · ╰── Invalid sign. Allowed signs are +, - ╰──── ~> {week: 10, day: -2, sign: '+'} | into duration Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #5:1:17] 1 │ {week: 10, day: -2, sign: '+'} | into duration · ─┬ ──────┬────── · │ ╰── encountered here · ╰── number should be positive ╰──── ~> {week: 10, day: '2', sign: '+'} | into duration Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #6:1:17] 1 │ {week: 10, day: '2', sign: '+'} | into duration · ─┬─ ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰──── ~> {week: 10, unknown: 1} | into duration Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #7:1:1] 1 │ {week: 10, unknown: 1} | into duration · ───────────┬────────── ──────┬────── · │ ╰── Column 'unknown' is not valid for a structured duration. Allowed columns are: week, day, hour, minute, second, millisecond, microsecond, nanosecond, sign · ╰── value originates from here ╰──── ~> {week: 10, day: 2, sign: '+'} | into duration --unit sec Error: nu:🐚:incompatible_parameters × Incompatible parameters. ╭─[entry #2:1:33] 1 │ {week: 10, day: 2, sign: '+'} | into duration --unit sec · ──────┬────── ─────┬──── · │ ╰── the units should be included in the record · ╰── got a record as input ╰──── ``` # Tests + Formatting - Add examples and integration tests for ``into duration`` - Add one test for ``into duration`` # After Submitting If this is merged in time, I'll update my PR on the "datetime handling highlights" for the release notes.	2025-04-19 18:29:12 -05:00
Loïc Riegel	c8c018452f	Bugfix chrono panic + hotifx PR15544 (#15549) ... Closes #13972 # Description First commit: a hotfix concerning my last PR #15544! I had a ``unwrap_or_default`` that resulted in all years before ~1800 being considered as "now", because the ``num_nanoseconds()`` overflowed. Cc @fdncred Second: about #13972 Negative years are not allowed with RFC 2822 formatting, so I fallback RTC 3339 in such cases. If you want you might Rebase and Merge, and not squash. # User-Facing Changes On master 🔴 : ```nu ~> {year: 1900} | into datetime Mon, 1 Jan 1900 00:00:00 +0200 (125 years ago) # OK ~> {year: 1000} | into datetime Wed, 1 Jan 1000 00:00:00 +0200 (now) # NOT OK: now? ~> {year: -1000} | into datetime -1000-01-01T00:00:00+02:00 (now) # NOT OK: now? ~> {year: -1000} | into datetime | format date Error: × Main thread panicked. ├─▶ at C:\Users\RIL1RT\.cargo\registry\src\index.crates.io-6f17d22bba15001f\chrono-0.4.39\src\datetime\mod.rs:626:14 ╰─▶ writing rfc2822 datetime to string should never fail: Error help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace. # NOT OK: panics ``` On this branch 🟢 : ```nu ~> {year: 1900} | into datetime Mon, 1 Jan 1900 00:00:00 +0200 (in 125 years) ~> {year: 1000} | into datetime Wed, 1 Jan 1000 00:00:00 +0200 (1025 years ago) ~> {year: -1000} | into datetime -1000-01-01T00:00:00+02:00 (3025 years ago) ~> {year: -1000} | into datetime | format date -1000-01-01T00:00:00+02:00 ~> '3000 years ago' | date from-human | format date -0975-04-11T18:18:24.301641100+02:00 ``` # Tests + Formatting # After Submitting Nothing required IMO	2025-04-11 11:52:42 -05:00
Loïc Riegel	dfca117551	Feat: construct datetime from record (#15455) ... Issue #12289, can be closed when this is merged # Description Currently, the ``into datetime`` command's signature indicates that it supports input as record, but it was actually not supported. This PR implements this feature. # User-Facing Changes ``into datetime``'s signature changed (see comments) **Happy paths** Note: I'm in +02:00 timezone. ```nushell > date now | into record | into datetime Fri, 4 Apr 2025 18:32:34 +0200 (now) > {year: 2025, month: 12, day: 6, second: 59} | into datetime | into record ╭─────────────┬────────╮ │ year │ 2025 │ │ month │ 12 │ │ day │ 6 │ │ hour │ 0 │ │ minute │ 0 │ │ second │ 59 │ │ millisecond │ 0 │ │ microsecond │ 0 │ │ nanosecond │ 0 │ │ timezone │ +02:00 │ ╰─────────────┴────────╯ > {day: 6, second: 59, timezone: '-06:00'} | into datetime | into record ╭─────────────┬────────╮ │ year │ 2025 │ │ month │ 4 │ │ day │ 6 │ │ hour │ 0 │ │ minute │ 0 │ │ second │ 59 │ │ millisecond │ 0 │ │ microsecond │ 0 │ │ nanosecond │ 0 │ │ timezone │ -06:00 │ ╰─────────────┴────────╯ ``` **Edge cases** ```nushell {} | into datetime Fri, 4 Apr 2025 18:35:19 +0200 (now) ``` **Error paths** - A key has a wrong type ```nushell > {month: 12, year: '2023'} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #8:1:19] 1 │ {month: 12, year: '2023'} | into datetime · ───┬── ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰──── ``` ```nushell > {month: 12, year: 2023, timezone: 100} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #10:1:35] 1 │ {month: 12, year: 2023, timezone: 100} | into datetime · ─┬─ ──────┬────── · │ ╰── only string input data is supported · ╰── input type: int ╰──── ``` - Key has the right type but value invalid (e.g. month=13, or day=0) ```nushell > {month: 13, year: 2023} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #9:1:1] 1 │ {month: 13, year: 2023} | into datetime · ───────────┬─────────── ──────┬────── · │ ╰── one of more values are incorrect and do not represent valid date · ╰── encountered here ╰──── ``` ```nushell > {hour: 1, minute: 1, second: 70} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #3:1:1] 1 │ {hour: 1, minute: 1, second: 70} | into datetime · ────────────────┬─────────────── ──────┬────── · │ ╰── one of more values are incorrect and do not represent valid time · ╰── encountered here ╰──── ``` - Timezone has right type but is invalid ```nushell > {month: 12, year: 2023, timezone: "+100:00"} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #11:1:35] 1 │ {month: 12, year: 2023, timezone: "+100:00"} | into datetime · ────┬──── ──────┬────── · │ ╰── encountered here · ╰── invalid timezone ╰──── ``` - Record contains an invalid key ```nushell > {month: 12, year: 2023, unknown: 1} | into datetime Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #12:1:1] 1 │ {month: 12, year: 2023, unknown: 1} | into datetime · ─────────────────┬───────────────── ──────┬────── · │ ╰── Column 'unknown' is not valid for a structured datetime. Allowed columns are: year, month, day, hour, minute, second, millisecond, microsecond, nanosecond, timezone · ╰── value originates from here ╰──── ``` - If several issues are present, the user can get the error msg for only one, though ```nushell > {month: 20, year: '2023'} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #7:1:19] 1 │ {month: 20, year: '2023'} | into datetime · ───┬── ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰ ``` # Tests + Formatting Tests added Fmt + clippy OK # After Submitting Maybe indicate that in the release notes I added an example in the command, so the documentation will be automatically updated.	2025-04-10 15:33:06 +02:00
Antoine Stevan	79359598db	add table -> table to into datetime (#9775) ... should close https://github.com/nushell/nushell/issues/9774 # Description given the help page of `into datetime`, ``` Parameters: ...rest <cellpath>: for a data structure input, convert data at the given cell paths ``` it looks like `into datetime` should accept tables as input 🤔 this PR - adds the `table -> table` signature to `into datetime` - adds a test to make sure the behaviour stays there	2023-07-23 20:14:51 +02:00