Repository navigation
Labels
A:datetime-handlingSemantics and implementation of the datetime/duration types and commandsSemantics and implementation of the datetime/duration types and commandscategory:upstreamproblem with upstream dependencyproblem with upstream dependencyhelp wantedstatus: Extra attention is neededstatus: Extra attention is needed
Milestone
Description
Describe the bug
When starting Nushell, a Type mismatch error occurs in default_env.nu at line 25, related to the format date '%x %X' command. The system reports it as an "invalid format"
~> nu
Error: nu::shell::type_mismatch
× Type mismatch.
╭─[default_env.nu:25:33]
24 │ (ansi magenta)
25 │ (date now | format date '%x %X') # try to respect user's locale
· ───┬───
· ╰── invalid format
26 │ ] | str join | str replace --regex --all "([/:])" $"(ansi green)${1}(ansi magenta)" |
╰────
Environment
OS: Fedora Linux 41 (Workstation Edition) x86_64
Nushell version: 0.102.0
~> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=th_TH.UTF-8
LC_TIME=th_TH.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=th_TH.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=th_TH.UTF-8
LC_NAME="en_US.UTF-8"
LC_ADDRESS=th_TH.UTF-8
LC_TELEPHONE=th_TH.UTF-8
LC_MEASUREMENT=th_TH.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
How to reproduce
- Start Nushell using the nu command
- The system attempts to load default_env.nu which uses format date '%x %X' to display date and time according to user's locale
- A Type mismatch error occurs due to invalid format
Expected behavior
The command date now | format date '%x %X' should display date and time according to the user's locale settings without errors
Configuration
| key | value |
|---|---|
| version | 0.102.0 |
| major | 0 |
| minor | 102 |
| patch | 0 |
| branch | |
| commit_hash | 1aa2ed1 |
| build_os | linux-x86_64 |
| build_target | x86_64-unknown-linux-musl |
| rust_version | rustc 1.82.0 (f6e511eec 2024-10-15) |
| rust_channel | 1.82.0-x86_64-unknown-linux-gnu |
| cargo_version | cargo 1.82.0 (8f40fc59f 2024-08-21) |
| build_time | 2025-02-05 00:56:06 +00:00 |
| build_rust_channel | release |
| allocator | mimalloc |
| features | default, sqlite, static-link-openssl, trash |
| installed_plugins |
Reacted by Ali Naserinia
Metadata
Metadata
Assignees
Labels
A:datetime-handlingSemantics and implementation of the datetime/duration types and commandsSemantics and implementation of the datetime/duration types and commandscategory:upstreamproblem with upstream dependencyproblem with upstream dependencyhelp wantedstatus: Extra attention is neededstatus: Extra attention is needed
Activity
fdncred commentedon Mar 7, 2025
No issues on Windows with 0.102.1 (latest main branch/nightly)
or on WSL Ubuntu with 0.102.1 (latest main branch/nightly)
sgvictorino commentedon Mar 7, 2025
Reproduced on Linux (main):
fdncred commentedon Mar 7, 2025
It looks like it's just calling
sys_locale::get_locale. Maybe there's a bug upstream with that crate? I guess you'd have to see whatget_system_locale_string()is returning.sgvictorino commentedon Mar 7, 2025
This seems to affect any locale that uses the
%Emodifier, which is unimplemented bychrono:Pantakit-Joseph commentedon Mar 7, 2025
The command date now | format date '%x %X' doeswork as it should now with$env.LC_TIME=en_US.UTF-8`, and outputs the default date and time of "03/08/2025 02:39:28 AM" correctly.
But a "Type mismatch" error came along when the value of $env.LC_TIME changed to "th_TH.UTF-8", like this:
fdncred commentedon Mar 7, 2025
No clue how to handle the %E modifier.
foxmean commentedon Aug 1, 2025
I can reproduced this bug on NixOS 25.05 machine but not on macOS macOS Sequoia version 15.6 even if I set
$env.LC_TIME = "th_TH.UTF-8". This is maybe only bug on GNU/Linux system somehow?fix(format date): render locales whose format carries %E or %O (nushe…
fix(format date): resolve `%r` when the locale's am/pm fallback also …