<!--
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!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This is a direct port of the python polars command `convert_time_zone`
(https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.dt.convert_time_zone.html).
Consistent with the rust/python implementation, naive datetimes are
treated as if they are in UTC time.
```nushell
# Convert timezone for timezone-aware datetime
> ["2025-04-10 09:30:00 -0400" "2025-04-10 10:30:00 -0400"] | polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S %z"
| polars select (polars col datetime | polars convert-time-zone "Europe/Lisbon")
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 04/10/2025 02:30:00PM │
│ 1 │ 04/10/2025 03:30:00PM │
╰───┴───────────────────────╯
# Timezone conversions for timezone-naive datetime will assume the original timezone is UTC
> ["2025-04-10 09:30:00" "2025-04-10 10:30:00"] | polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars convert-time-zone "America/New_York")
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 04/10/2025 05:30:00AM │
│ 1 │ 04/10/2025 06:30:00AM │
╰───┴───────────────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have access to a new command `polars
convert-time-zone`
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Example tests have been added.
# 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.
-->
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
<!--
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!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR seeks to add a direct port of the python polars
`replace_time_zone` command in the `dt` namespace
(https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.dt.replace_time_zone.html).
Please note: I opted for two keywords "dt" and "replace-time-zone" to
map directly with the implementation in both the rust and python
packages, but I'm open to simplifying it to just one keyword, or `polars
replace-time-zone`
```nushell
# Apply timezone to a naive datetime
> ["2021-12-30 00:00:00" "2021-12-31 00:00:00"] | polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars dt replace-time-zone "America/New_York")
╭───┬─────────────────────╮
│ # │ datetime │
├───┼─────────────────────┤
│ 0 │ 12/30/21 12:00:00AM │
│ 1 │ 12/31/21 12:00:00AM │
╰───┴─────────────────────╯
# Apply timezone with ambiguous datetime
> ["2025-11-02 00:00:00", "2025-11-02 01:00:00", "2025-11-02 02:00:00", "2025-11-02 03:00:00"]
| polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars dt replace-time-zone "America/New_York" --ambiguous null)
╭───┬─────────────────────╮
│ # │ datetime │
├───┼─────────────────────┤
│ 0 │ 11/02/25 12:00:00AM │
│ 1 │ │
│ 2 │ 11/02/25 02:00:00AM │
│ 3 │ 11/02/25 03:00:00AM │
╰───┴─────────────────────╯
# Apply timezone with nonexistent datetime
> ["2025-03-09 01:00:00", "2025-03-09 02:00:00", "2025-03-09 03:00:00", "2025-03-09 04:00:00"]
| polars into-df
| polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
| polars select (polars col datetime | polars dt replace-time-zone "America/New_York" --nonexistent null)
╭───┬─────────────────────╮
│ # │ datetime │
├───┼─────────────────────┤
│ 0 │ 03/09/25 01:00:00AM │
│ 1 │ │
│ 2 │ 03/09/25 03:00:00AM │
│ 3 │ 03/09/25 04:00:00AM │
╰───┴─────────────────────╯
```
# User-Facing Changes
No breaking changes. The user will be able to access the new command.
# Tests + Formatting
See example tests.
# After Submitting
This addresses color issue; Yeees just got forgotten it :(
As far as I understand an acceptance test can't be created because ansi
got stripped in `nu!`. (for future regressions)
But wrapping I need to take a deeper look.
Maybe in an hour.
cc: @fdncred
Hi,
This PR should close 3 issues
- [DMY date format is parsed inconsistently
#14123](https://github.com/nushell/nushell/issues/14123)
- [into datetime doesnt't work with --format and ignores user's locale
#11015](https://github.com/nushell/nushell/issues/11015)
- [into datetime: iinconsistent and incrrect behaviour regarding
timezones #13823](https://github.com/nushell/nushell/issues/13823)
# Description
- Allow to parse only dates or only times with --format
- Use local timezone depending on the input. Ex: I'm in France, so show
dates with +0100 in winter and +0200 in summer.
```nushell
# Concerning #13823
> "2020-01-01 12:00" | into datetime
Wed, 1 Jan 2020 12:00:00 +0100 (5 years ago)
# OK, it's my timezone in winter time
> "2020-06-01 12:00" | into datetime
Mon, 1 Jun 2020 12:00:00 +0200 (4 years ago)
# OK, it's my timezone in summertime
> ("2024-10-27 12:00" | into datetime) - ("2024-10-27 00:00" | into datetime)
13hr
# Ok, because we switched from summer to winter time on 2025-10-27, so there are actually 13h between midnight and noon
> "2020-01-01 12:00" | into datetime --format "%Y-%m-%d %H:%M"
Wed, 1 Jan 2020 12:00:00 +0100 (5 years ago)
# OK: timezone is assumed to be local, and +0100 is my timezone in winter
# Concerning #14123 and #11015
# Flexible parsing still works like before, which could be counter-intuitive, but it's flexible parsing
# with one difference: the timezone is local
> '12-01-2001' | into datetime
Sat, 1 Dec 2001 00:00:00 +0100 (23 years ago)
# OK, +0100 is my timezone in winter time. If I run it with nushell 0.103.0 in summer time, I get +0200
> '13-01-2001' | into datetime
Sat, 13 Jan 2001 00:00:00 +0100 (24 years ago)
## If you want, you can use the --format option to parse a date or a time (before, it had to be a date + time)
## Notice here again the timezone is correct depending on winter/summer time
~> "06.03.2023" | into datetime -f "%d.%m.%Y"
Mon, 6 Mar 2023 00:00:00 +0100 (2 years ago)
~> "06.03.2023" | into datetime -f "%m.%d.%Y"
Sat, 3 Jun 2023 00:00:00 +0200 (2 years ago)
> "10:00" | into datetime --format "%H:%M"
Thu, 10 Apr 2025 10:00:00 +0200 (9 hours ago)
```
# User-Facing Changes
See above
# Tests + Formatting
# After Submitting
I'll down something for the release notes, if this is merged in time 😄
<!--
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!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR should close#15474 .
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
When users set the match algorithm to 'substring' by modifying
`$env.config` to `$env.config.completions.algorithm = "substring"``),
completions are done based on substring matches.
This was previously possible by setting `positional` to be false in
custom completers, but doing so now logs a warning as this feature is
set to be deprecated and replaced by the new way of setting the matching
algorithm to substring based.
# Description
Introduces `polars into-schema` which allows converting Values such as
records to a schema. This implicitly happens when when passing records
into commands like `polars into-df` today. This allows you to convert to
a schema object ahead of time and reuse the schema object. This can be
useful for guaranteeing your schema object is correct.
```nu
> ❯ : let schema = ({name: str, type: str} | polars into-schema)
> ❯ : ls | select name type | polars into-lazy -s $schema | polars schema
╭──────┬─────╮
│ name │ str │
│ type │ str │
╰──────┴─────╯
```
# User-Facing Changes
- Introduces `polars into-schema` allowing records to be converted to
schema objects.
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.
# Description
This PR tries to fix the datetime-diff custom command so that it
includes ms, us, ns.
Difference in the banner in 2 separate starts.
### Old
```nushell
It's been this long since Nushell's first commit:
5yrs 10months 29days 9hrs 1min 47secs
```
### New
```nushell
It's been this long since Nushell's first commit:
5yrs 10months 29days 9hrs 1min 22secs 49ms 885µs
```
There should be ns above on the new one, not sure why there isn't. It
could have something to do with how the banner works but i'll save that
for another PR.
🤔 It could be because there are no fractional seconds in the math?
`datetime-diff (date now) 2019-05-10T09:59:12-07:00`. However, I'm not
sure why `date now` has no nanoseconds. Oh, wait. I think that's because
MacOS doesn't have nanosecond precision?
```
❯ ^date +%s.%N
1744251636.365003000
```
Closes https://github.com/nushell/nushell/issues/15524
/cc @NotTheDr01ds
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# 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.
-->
# Description
I've made the panic reproducible in test case
`workspace::tests::quoted_command_reference_in_workspace`.
This PR fixes that by parsing + merging 1 more time, IMO it's a small
price to pay for workspace-wide heavy requests.
# User-Facing Changes
bug fix
# Tests + Formatting
made 1 case harder
# After Submitting
# Description
This pull request does a lot of the heavy lifting needed to supported
more complex dtypes like categorical dtypes. It introduces a new
CustomValue, NuDataType and makes NuSchema a full CustomValue. Further
more it introduces a new command `polars into-dtype` that allows a dtype
to be created. This can then be passed into schemas when they are
created.
```nu
> ❯ : let dt = ("str" | polars to-dtype)
> ❯ : [[a b]; ["one" "two"]] | polars into-df -s {a: $dt, b: str} | polars schema
╭───┬─────╮
│ a │ str │
│ b │ str │
╰───┴─────╯
```
# User-Facing Changes
- Introduces new command `polars into-dtype`, allows dtype variables to
be passed in during schema creation.
Bumps [indexmap](https://github.com/indexmap-rs/indexmap) from 2.8.0 to
2.9.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/indexmap-rs/indexmap/blob/main/RELEASES.md">indexmap's
changelog</a>.</em></p>
<blockquote>
<h2>2.9.0 (2025-04-04)</h2>
<ul>
<li>Added a <code>get_disjoint_mut</code> method to
<code>IndexMap</code>, matching Rust 1.86's
<code>HashMap</code> method.</li>
<li>Added a <code>get_disjoint_indices_mut</code> method to
<code>IndexMap</code> and <code>map::Slice</code>,
matching Rust 1.86's <code>get_disjoint_mut</code> method on
slices.</li>
<li>Deprecated the <code>borsh</code> feature in favor of their own
<code>indexmap</code> feature,
solving a cyclic dependency that occured via
<code>borsh-derive</code>.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="1818d4140d"><code>1818d41</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/387">#387</a>
from cuviper/release-2.9.0</li>
<li><a
href="9f4998341b"><code>9f49983</code></a>
Release 2.9.0</li>
<li><a
href="582a90fda3"><code>582a90f</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/386">#386</a>
from cuviper/de-borsh</li>
<li><a
href="90117397b6"><code>9011739</code></a>
Deprecate the "borsh" feature</li>
<li><a
href="0a836e8648"><code>0a836e8</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/238">#238</a>
from NiklasJonsson/get_many_mut</li>
<li><a
href="434d7ac6d1"><code>434d7ac</code></a>
Avoid let-else for MSRV's sake</li>
<li><a
href="5be552d557"><code>5be552d</code></a>
Implement additional suggestions from review</li>
<li><a
href="4e1d8cef47"><code>4e1d8ce</code></a>
Address review feedback</li>
<li><a
href="5aec9ec674"><code>5aec9ec</code></a>
Implement get_disjoint_mut for arrays of keys</li>
<li><a
href="d10de30e74"><code>d10de30</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/385">#385</a>
from iajoiner/docs/macros</li>
<li>Additional commits viewable in <a
href="https://github.com/indexmap-rs/indexmap/compare/2.8.0...2.9.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
I think after that we can close #14790
# Description
So the issue was the tiny time delta between the moment the "date
form-human" command is executed, and the moment the value gets
displayed, using chrono_humanize.
When in inputing "in 30 seconds", we currently get:
```
[crates\nu-protocol\src\value\mod.rs:950:21] HumanTime::from(*val) = HumanTime(
TimeDelta {
secs: 29,
nanos: 992402700,
},
)```
And with "now":
```
crates\nu-protocol\src\value\mod.rs:950:21] HumanTime::from(*val) =
HumanTime(
TimeDelta {
secs: -1,
nanos: 993393200,
},
)
```
My solution is to round this timedelta to seconds and pass this to chrono_humanize.
Example: instead of passing (-1s + 993393200ns), we pass 0s.
Example: instead of passing (29s + 992402700ns), we pass 30s
# User-Facing Changes
Before 🔴
```nushell
~> "in 3 days" | date from-human
Fri, 11 Apr 2025 09:06:36 +0200 (in 2 days)
~> "in 30 seconds" | date from-human
Tue, 8 Apr 2025 09:07:09 +0200 (in 29 seconds)
```
After those changes 🟢
```nushell
~> "in 3 days" | date from-human
Fri, 11 Apr 2025 09:03:47 +0200 (in 3 days)
~> "in 30 seconds" | date from-human
Tue, 8 Apr 2025 09:04:28 +0200 (in 30 seconds)
```
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it automatically
> toolkit check pr
> ```
-->
# 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. -->
# Description
Now, with PWD correctly set in #15470 , identifiers in
`use/hide/overlay` commands can be identified using a more robust
method, i.e. module_id from `parser_info`.
# User-Facing Changes
bug fix
# Tests + Formatting
+1 (fails without this PR)
# After Submitting
# Description
The current implementation of `polars into-df` and `polars into-lazy`
will throw an error if `--schema` is provided but not all columns are
defined. This PR seeks to remove this requirement so that when a partial
`--schema` is provided, the types on the defined columns are overridden
while the remaining columns take on their default types.
**Current Implementation**
```
$ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df -s {a: str} | polars schema
Error: × Schema does not contain column: b
╭─[entry #88:1:12]
1 │ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df -s {a: str} | polars schema
· ─────
╰────
```
**New Implementation (no error thrown on partial schema definition)**
Column b is not defined in `--schema`
```
$ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df --schema {a: str} | polars schema
╭───┬─────╮
│ a │ str │
│ b │ str │
╰───┴─────╯
```
# User-Facing Changes
Soft breaking change: The user's previous (erroneous) code that would
have thrown an error would no longer throw an error. The user's previous
working code will still work.
# Tests + Formatting
# After Submitting
No related issue.
Decided in nushell's weekly meeting: see [meeting
notes](https://hackmd.io/rA1YecqjRh6I5m8dTq7BHw)
# Description
Converting a date as a human readable string to a datetime:
- currently: using the ``into datetime`` command
- after this change: using ``date from-human`` command
Also moved the ``--list-human`` flag to the new command.
# User-Facing Changes
- Users have to use a new command for parsing human readable datetimes.
Result:
```nushell
~> date from-human --list
╭────┬───────────────────────────────────┬──────────────╮
│ # │ parseable human datetime examples │ result │
├────┼───────────────────────────────────┼──────────────┤
│ 0 │ Today 18:30 │ in 6 hours │
│ 1 │ 2022-11-07 13:25:30 │ 2 years ago │
│ 2 │ 15:20 Friday │ in 6 days │
│ 3 │ This Friday 17:00 │ in 6 days │
│ 4 │ 13:25, Next Tuesday │ in 3 days │
│ 5 │ Last Friday at 19:45 │ 16 hours ago │
│ 6 │ In 3 days │ in 2 days │
│ 7 │ In 2 hours │ in 2 hours │
│ 8 │ 10 hours and 5 minutes ago │ 10 hours ago │
│ 9 │ 1 years ago │ a year ago │
│ 10 │ A year ago │ a year ago │
│ 11 │ A month ago │ a month ago │
│ 12 │ A week ago │ a week ago │
│ 13 │ A day ago │ a day ago │
│ 14 │ An hour ago │ an hour ago │
│ 15 │ A minute ago │ a minute ago │
│ 16 │ A second ago │ now │
│ 17 │ Now │ now │
╰────┴───────────────────────────────────┴──────────────╯
~> "2 days ago" | date from-human
Thu, 3 Apr 2025 12:03:33 +0200 (2 days ago)
~> "2 days ago" | into datetime
Error: nu:🐚:datetime_parse_error
× Unable to parse datetime: [2 days ago].
╭─[entry #5:1:1]
1 │ "2 days ago" | into datetime
· ──────┬─────
· ╰── datetime parsing failed
╰────
help: Examples of supported inputs:
* "5 pm"
* "2020/12/4"
* "2020.12.04 22:10 +2"
* "2020-04-12 22:10:57 +02:00"
* "2020-04-12T22:10:57.213231+02:00"
* "Tue, 1 Jul 2003 10:52:37 +0200"
```
# Tests + Formatting
Fmt, clippy 🆗
Tests 🆗
> Note: I was able to reactivate one unit test in the ``into datetime``
command
# After Submitting
Here since the user facing changes are significant, I think we should
communicate in the released notes. Otherwise the automatically generated
documentation should be enough IMO.
Closes#15502
# Description
The parsing of Exbibytes used the wrong base unit before converting.
# User-Facing Changes
`1EiB` etc. will now be parsed correctly
# Tests + Formatting
(-)
sub-issue of #10698 according to @sholderbach
(Description largely edited, since the scope of the PR changed)
# Description
Context: `ShellError::OnlySupportsThisInputType` was a duplicate of
`ShellError::PipelineMismatch`
so I
- replaced some occurences of PipelineMismatch by
OnlySupportsThisInputType
For another PR
- replace the remaining occurences
- removed OnlySupportsThisInputType from nu-protocol
# User-Facing Changes
The error message will be different -> but consistent
# Tests + Formatting
OK
# After Submitting
Nothing required
#15499 reminds me of the discrepancies between lsp hover docs and
`--help` outputs.
# Description
# User-Facing Changes
Before:
<img width="610" alt="image"
src="https://github.com/user-attachments/assets/f73f7ace-5c1b-4380-9921-fb4783bdb187"
/>
After:
<img width="610" alt="image"
src="https://github.com/user-attachments/assets/96de3ffe-e37b-41b1-88bb-123eeb72ced2"
/>
Output of `if -h` as a reference:
```
Usage:
> if <cond> <then_block> (else <else_expression>)
Flags:
-h, --help: Display the help message for this command
Parameters:
cond <variable>: Condition to check.
then_block <block>: Block to run if check succeeds.
"else" + <one_of(block, expression)>: Expression or block to run when the condition is false. (optional)
```
# Tests + Formatting
Refined
# After Submitting
# Description
There are some clippy(version 0.1.86) errors on nushell repo. This pr is
trying to fix it.
# User-Facing Changes
Hopefully none.
# Tests + Formatting
NaN
# After Submitting
NaN
# Description
Some editors like neovim will provide "workspace root" as PWD, which can
mess up file completion results.
# User-Facing Changes
bug fix
# Tests + Formatting
adjusted
# After Submitting
# Description
This PR seeks to fix an error in `polars as-datetime` where timezone
information is entirely ignored. This behavior raises a host of silent
errors when dealing with datetime conversions (see example below).
## Current Implementation
Timezones are entirely ignored and datetimes with different timezones
are converted to the same naive datetimes even when the user
specifically indicates that the timezone should be parsed. For example,
"2021-12-30 00:00:00 +0000" and "2021-12-30 00:00:00 -0400" will both be
parsed to "2021-12-30 00:00:00" even when the format string specifically
includes "%z".
```
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z"
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 12/30/2021 12:00:00AM │
│ 1 │ 12/30/2021 12:00:00AM │ <-- Same datetime even though the first is +0000 and second is -0400
╰───┴───────────────────────╯
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" | polars schema
╭──────────┬──────────────╮
│ datetime │ datetime<ns> │
╰──────────┴──────────────╯
```
## New Implementation
Datetimes are converted to UTC and timezone information is retained.
```
$ "2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z"
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 12/30/2021 12:00:00AM │
│ 1 │ 12/30/2021 04:00:00AM │ <-- Converted to UTC
╰───┴───────────────────────╯
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" | polars schema
╭──────────┬───────────────────╮
│ datetime │ datetime<ns, UTC> │
╰──────────┴───────────────────╯
```
The user may intentionally ignore timezone information by setting the
`--naive` flag.
```
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" --naive
╭───┬───────────────────────╮
│ # │ datetime │
├───┼───────────────────────┤
│ 0 │ 12/30/2021 12:00:00AM │
│ 1 │ 12/30/2021 12:00:00AM │ <-- the -0400 offset is ignored when --naive is set
╰───┴───────────────────────╯
$ ["2021-12-30 00:00:00 +0000" "2021-12-30 00:00:00 -0400"] | polars into-df | polars as-datetime "%Y-%m-%d %H:%M:%S %z" --naive | polars schema
╭──────────┬──────────────╮
│ datetime │ datetime<ns> │
╰──────────┴──────────────╯
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
`polars as-datetime` will now account for timezone information and
return type `datetime<ns,UTC>` rather than `datetime<ns>` by default.
The user can replicate the previous behavior by setting `--naive`.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Tests that incorporated `polars as-datetime` had to be tweaked to
include `--naive` flag to replicate previous behavior.
# 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.
-->
<!--
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!
-->
Fixes#15476
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Consider PATH when checking for potential_nuscript_in_windows to allow
executing scripts which are in PATH without having to full path address
them. It previously only checked the current working directory so only
relative paths to cwd and full path worked.
The current implementation runs this then through cmd.exe /D /C which
can run it with assoc and ftype set for nushell scripts.
We could instead run it through nu as `std::env::current_exe()` avoiding
the cmd call and the need for assoc and ftype (see:
8b25173f02).
But ive left the current implementation for this intact to not change
implementation details, avoid a bigger change and leave this open for
discussion here since im not sure if this has any major implications.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
This would now run every external command through PATH an additional
time on windows, so potentially twice. I dont think this has any bigger
effect.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# 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.
-->
# Description
Noticed there is a build failure in #15420, because `ShadowBuilder`
struct is guarded by `build` feature. This pr is going to update it.
# User-Facing Changes
Hopefully none.
# Tests + Formatting
None
# After Submitting
None
---------
Co-authored-by: Stefan Holderbach <sholderbach@users.noreply.github.com>
Issue #9887 which can be closed after this is merged.
# Description
This allows the "into duration" command to accept floats as inputs.
Examples:
<img width="767" alt="image"
src="https://github.com/user-attachments/assets/da181f2a-7ad6-4efb-a6db-f9c6d8929c71"
/>
<img width="710" alt="image"
src="https://github.com/user-attachments/assets/78623a39-33ad-42a0-9324-a147be86f95c"
/>
**How it works:**
Using strings, like `"1.234sec" | into duration`, is already working, so
if a user inputs `1.234 | into duration --sec`, I just convert this back
to a string and use the previous conversion functions.
**Limitations:**
there are some limitation to using floats, but it's a general limitation
that is already present for other use cases:
- only 3 digits are taken into account in the decimal part
- floating durations in nano seconds are always floored and not rounded
<img width="761" alt="image"
src="https://github.com/user-attachments/assets/a9076aab-da03-43f2-927c-c9703fc4f955"
/>
# User-Facing Changes
Users can inject floats with `into duration`
# Tests + Formatting
cargo fmt and clippy OK
Tests OK
# After Submitting
The example I added will automatically become part of the doc, I think
that's enough for documentation.
This should be a more robust method.
# Description
Previously, `export use` with double-space in between will fail to be
recognized as command `export use`.
# User-Facing Changes
minor bug fix
# Tests + Formatting
test cases made harder
# After Submitting
<!--
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!
-->
# Description
This PR expands the `dtype` parameter of the `polars cast` command to
include `decimal<precision, scale>` type. Setting precision to "*" will
compel inferring the value. Note, however, setting scale to a
non-integer value will throw an explicit error (the underlying polars
crate assigns scale = 0 in such a case, but I opted for throwing an
error instead). .
```
$ [[a b]; [1 2] [3 4]] | polars into-df | polars cast decimal<4,2> a | polars schema
╭───┬──────────────╮
│ a │ decimal<4,2> │
│ b │ i64 │
╰───┴──────────────╯
$ [[a b]; [10.5 2] [3.1 4]] | polars into-df | polars cast decimal<*,2> a | polars schema
╭───┬──────────────╮
│ a │ decimal<*,2> │
│ b │ i64 │
╰───┴──────────────╯
$ [[a b]; [10.05 2] [3.1 4]] | polars into-df | polars cast decimal<5,*> a | polars schema
rror: × Invalid polars data type
╭─[entry #25:1:47]
1 │ [[a b]; [10.05 2] [3.1 4]] | polars into-df | polars cast decimal<5,*> a | polars schema
· ─────┬─────
· ╰── `*` is not a permitted value for scale
╰────
```
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
There are no breaking changes. The user has the additional option to
`polars cast` to a decimal type
# Tests + Formatting
Tests have been added to
`nu_plugin_polars/src/dataframe/values/nu_schema.rs`
# Description
There's been much debate about whether to keep human-date-parser in
`into datetime`. We saw recently that a new version of the crate was
released that addressed some of our concerns. This PR is to make it
easier to test those fixes.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# 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.
-->
<!--
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!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Follow-up to #15277 and #15392.
Adds examples to `any` and `all` demonstrating using `any {}` or `all
{}` with lists of booleans.
We have a couple options that work for this use-case, but not sure which
we should recommend. The PR currently uses (1).
1. `any {}` / `all {}`
2. `any { $in }` / `all { $in }`
3. `any { $in == true }` / `all { $in == true }`
Would love to hear your thoughts on the above @fennewald @mtimaN
@fdncred @NotTheDr01ds @ysthakur
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Added an extra example for `any` and `all`
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
N/A
# 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.
-->
N/A
# Description
As description, I think it's worth to move forward to update rand and
rand_chacha to 0.9.
# User-Facing Changes
Hopefully none
# Tests + Formatting
NaN
# After Submitting
NaN
# Description
```
# table.*
# table_mode (string):
# One of: "default", "basic", "compact", "compact_double", "heavy", "light", "none", "reinforced",
# "rounded", "thin", "with_love", "psql", "markdown", "dots", "restructured", "ascii_rounded",
# or "basic_compact"
# Can be overridden by passing a table to `| table --theme/-t`
$env.config.table.mode = "default"
```
In `doc_config.nu`, it refers to `table_mode` which does not exist under
`$env.config.table`. There is now a short description of this field as
well.
# Description
Closes#14794. This PR enables the strict exact match behavior requested
in #13204 and #14794 for any path containing a slash (#13302 implemented
this for paths ending in slashes).
If any of the components along the way *don't* exactly match a
directory, then the next components will use the old Fish-like
completion behavior rather than the strict behavior.
This change only affects those using prefix matching. Fuzzy matching
remains unaffected.
# User-Facing Changes
Suppose you have the following directory structure:
```
- foo
- bar
- xyzzy
- barbaz
- xyzzy
- foobar
- bar
- xyzzy
- barbaz
- xyzzy
```
- If you type `cd foo<TAB>`, you will be suggested `[foo, foobar]`
- This is because `foo` is the last component of the path, so the strict
behavior isn't activated
- Similarly, `foo/bar` will show you `[foo/bar, foo/barbaz]`
- If you type `foo/bar/x`, you will be suggested `[foo/bar/xyzzy]`
- This is because `foo` and `bar` both exactly matched a directory
- If you type `foo/b/x`, you will be suggested `[foo/bar/xyzzy,
foo/barbaz/xyzzy]`
- This is because `foo` matches a directory exactly, so `foobar/*` won't
be suggested, but `b` doesn't exactly match a directory, so both `bar`
and `barbaz` are suggested
- If you type `f/b/x`, you will be suggested all four of the `xyzzy`
files above
- If you type `f/bar/x`, you will be suggested all four of the `xyzzy`
files above
- Since `f` doesn't exactly match a directory, every component after it
won't use the strict matching behavior (even though `bar` exactly
matches a directory)
# Tests + Formatting
# After Submitting
This is a pretty minor change but should be mentioned somewhere in the
release notes in case it surprises someone.
---------
Co-authored-by: 132ikl <132@ikl.sh>
<!--
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!
-->
Fixes#14794.
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Makes it so that (even if) the command ends in a slash, exact matches
are still preferred over partial matches.
For example, `foo/bar/as` -> `foo/bar/asdf` but not `foo/bars/asdf`.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# 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: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
# Description
Add parse warnings to LSP diagnostics, not particularly useful but
technically should be done.
# User-Facing Changes
# Tests + Formatting
There's no deprecated command to test for now.
# After Submitting
Fixes#15414 by changing the method used to de-ansi-fy the input. Control characters will now be kept when using `clip copy`, but ANSI escape codes will be removed (when not using `--ansi (-a)`)
Fixes#15441
# Description
Actually I made a small change to the original behavior:
```
^foo<tab>
```
will still show external commands, regardless of whether it's enabled or
not. I think that's the only thing people want to see when they press
tab with a `^` prefix.
# User-Facing Changes
# Tests + Formatting
+1
# After Submitting
Should I document that minor behavior change somewhere in GitHub.io?
---------
Co-authored-by: Yash Thakur <45539777+ysthakur@users.noreply.github.com>
Close#15119 when this is merged
# Description
> Note: my locale is +1
**Before the changes 🔴**
See the issue for more detailed description of the problem.
**After the changes 🟢**
# User-Facing Changes
The ``into datetime`` command will now work with formatting and time
zones or offset together
# Tests + Formatting
Fmt + clippy OK
**Note about the tests I added**: those tests don't really test my
changes, as they were already passing before my changes. Nevertheless I
thought I could push them
# After Submitting
I don't think anything is necessary
