mirror of
https://github.com/nushell/nushell.git
synced 2024-11-08 17:44:27 +01:00
570175f95d
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> This PR should close #8036, #9028 (in the negative) and #9118. Fix for #9118 is a bit pedantic. As reported, the issue is: ``` > 2023-05-07T04:08:45+12:00 - 2019-05-10T09:59:12+12:00 3yr 12month 2day 18hr 9min 33sec ``` with this PR, you now get: ``` > 2023-05-07T04:08:45+12:00 - 2019-05-10T09:59:12+12:00 208wk 1day 18hr 9min 33sec ``` Which is strictly correct, but could still fairly be called "weird date arithmetic". # Description * [x] Abide by constraint that Value::Duration remains a number of nanoseconds with no additional fields. * [x] `to_string()` only displays weeks .. nanoseconds. Duration doesn't have base date to compute months or years from. * [x] `duration | into record` likewise only has fields for weeks .. nanoseconds. * [x] `string | into duration` now accepts compound form of duration to_string() (e.g '2day 3hr`, not just '2day') * [x] `duration | into string` now works (and produces the same representation as to_string(), which may be compound). # User-Facing Changes ## duration -> string -> duration Now you can "round trip" an arbitrary duration value: convert it to a string that may include multiple time units (a "compound" value), then convert that string back into a duration. This required changes to `string | into duration` and the addition of `duration | into string'. ``` > 2day + 3hr 2day 3hr # the "to_string()" representation (in this case, a compound value) > 2day + 3hr | into string 2day 3hr # string value > 2day + 3hr | into string | into duration 2day 3hr # round-trip duration -> string -> duration ``` Note that `to nuon` and `from nuon` already round-tripped durations, but use a different string representation. ## potentially breaking changes * string rendering of a duration no longer has 'yr' or 'month' phrases. * record from `duration | into record` no longer has 'year' or 'month' fields. The excess duration is all lumped into the `week` field, which is the largest time unit you can convert to without knowing the datetime from which the duration was calculated. Scripts that depended on month or year time units on output will need to be changed. ### Examples ``` > 365day 52wk 1day ## Used to be: ## 1yr > 365day | into record ╭──────┬────╮ │ week │ 52 │ │ day │ 1 │ │ sign │ + │ ╰──────┴────╯ ## used to be: ##╭──────┬───╮ ##│ year │ 1 │ ##│ sign │ + │ ##╰──────┴───╯ > (365day + 4wk + 5day + 6hr + 7min + 8sec + 9ms + 10us + 11ns) 56wk 6day 6hr 7min 8sec 9ms 10µs 11ns ## used to be: ## 1yr 1month 3day 6hr 7min 8sec 9ms 10µs 11ns ## which looks reasonable, but was actually only correct in 75% of the years and 25% of the months in the last 4 years. > (365day + 4wk + 5day + 6hr + 7min + 8sec + 9ms + 10us + 11ns) | into record ╭─────────────┬────╮ │ week │ 56 │ │ day │ 6 │ │ hour │ 6 │ │ minute │ 7 │ │ second │ 8 │ │ millisecond │ 9 │ │ microsecond │ 10 │ │ nanosecond │ 11 │ │ sign │ + │ ╰─────────────┴────╯ ``` Strictly speaking, these changes could break an existing user script. Losing years and months as time units is arguably a regression in behavior. Also, the corrected duration calculation could break an existing script that was calibrated using the old algorithm. # Tests + Formatting ``` > toolkit check pr ``` - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> --------- Co-authored-by: Bob Hyman <bobhy@localhost.localdomain> |
||
|---|---|---|
| .. | ||
| nu_plugin_custom_values | ||
| nu_plugin_example | ||
| nu_plugin_formats | ||
| nu_plugin_gstat | ||
| nu_plugin_inc | ||
| nu_plugin_python | ||
| nu_plugin_query | ||
| nu-cli | ||
| nu-cmd-base | ||
| nu-cmd-dataframe | ||
| nu-cmd-extra | ||
| nu-cmd-lang | ||
| nu-color-config | ||
| nu-command | ||
| nu-engine | ||
| nu-explore | ||
| nu-glob | ||
| nu-json | ||
| nu-parser | ||
| nu-path | ||
| nu-plugin | ||
| nu-pretty-hex | ||
| nu-protocol | ||
| nu-std | ||
| nu-system | ||
| nu-table | ||
| nu-term-grid | ||
| nu-test-support | ||
| nu-utils | ||
| README.md | ||
Nushell core libraries and plugins
These sub-crates form both the foundation for Nu and a set of plugins which extend Nu with additional functionality.
Foundational libraries are split into two kinds of crates:
- Core crates - those crates that work together to build the Nushell language engine
- Support crates - a set of crates that support the engine with additional features like JSON support, ANSI support, and more.
Plugins are likewise also split into two types:
- Core plugins - plugins that provide part of the default experience of Nu, including access to the system properties, processes, and web-connectivity features.
- Extra plugins - these plugins run a wide range of different capabilities like working with different file types, charting, viewing binary data, and more.