I like it but don't think we can move forward with it unless it respects use_ansi_coloring. If use_ansi_coloring is false, all colors need to be removed. Some people have terminals that don't support coloring, believe it or not.

@sholderbach was also working on a ShellWarning system, although I'm not sure of it's status.

I like it but don't think we can move forward with it unless it respects use_ansi_coloring. If use_ansi_coloring is false, all colors need to be removed. Some people have terminals that don't support coloring, believe it or not.

very good catch 👏 👏
should be better with 848344c 👍

@sholderbach was also working on a ShellWarning system, although I'm not sure of it's status.

i'd be happy to use a better and more clever system 😌
this is my quick and dirty proposal for now 😉

thanks to @kubouch expertise, i've switched to using report_error and a GenericError to have pretty errors with span information 😋

( i force pushed the last commit only immediately to amend dc2f814 with a Clippy fix )

Let's move forward with this and see how it goes.

@amtoine My understanding is the --format flag of into datetime changes the input formatting, while date format only changes the output formatting. Feel free to correct me if I'm missing something.

https://github.com/amtoine/nushell/blob/c9ffc5696debd310c8aa4a81d85201fd5e7907ee/crates/nu-command/src/conversions/into/datetime.rs#L330C5-L334C71

// If input is not a timestamp, try parsing it as a string
    match input {
        Value::String { val, span } => {
            match dateformat {
                Some(dt) => match DateTime::parse_from_str(val, &dt.0)

From the documentation of parse_from_str:

Parses a string from a user-specified format into a DateTime value.

Oh, input format. That would make a lot of sense then, but the problem with no one knowing understanding what it did was a problem. LOL. Maybe we revert this and chose something other than -f and be more specific about it being and input-format.

so do we revert this PR? before the release?

Thanks for putting up a revert PR @amtoine. I'm still confused though because it seems that something isn't working right.

'20220604' | into datetime -f '%Y%m%d'

@jmoore34 Shouldn't this work or am I still missing the point to --format?

Maybe we need a better datetime parsing create. Seems silly that the first one would work but the last one wouldn't. I just took off the %z and +0000.

❯ '20210227_135540+0000' | into datetime -f '%Y%m%d_%H%M%S%z'
Sat, 27 Feb 2021 13:55:40 +0000 (2 years ago)
❯ '20210227_135540' | into datetime -f '%Y%m%d_%H%M%S'
Error: nu::shell::cant_convert

  × Can't convert to could not parse as datetime using format '%Y%m%d_%H%M%S'.
   ╭─[entry #12:1:1]
 1 │ '20210227_135540' | into datetime -f '%Y%m%d_%H%M%S'
   ·                     ──────┬──────
   ·                           ╰── can't convert input is not enough for unique date and time to could not parse as datetime using format '%Y%m%d_%H%M%S'
   ╰────
  help: you can use `into datetime` without a format string to enable flexible parsing

Seems like dtparse may be better? https://github.com/bspeice/dtparse
There's a bajillion tests https://github.com/bspeice/dtparse/blob/master/src/tests/pycompat_parser.rs

I kind of like this one too https://github.com/waltzofpearls/dateparser

I guess my thought with these is to make it parse more date/datetime strings without having to use the --format since it seems kind of hit and miss.