seems reasonable to me

Thanks! Should be ready now with a test case in place.

Thinking a bit more about this I'm wondering if this is right. Should we be converting an int to a string? You can clearly do date now | into int | into datetime and it works fine. You can also do 1722821463 * 1_000_000_000 | into datetime and it works fine because nushell wants int time stamps to be in nanoseconds. The question is, why does -f %s require a string?

Thinking a bit more about this I'm wondering if this is right. Should we be converting an int to a string? You can clearly do date now | into int | into datetime and it works fine.

Sure, the user can multiply the Unix epoch by 1_000_000_000 as well, but | to text is slightly more concise and readable to me. Three options:

> let times = [
    1722821463
    1722821584
    1722821588
  ]

# Option 1 - Unwieldy because of the multiplication/conversion
> $times | each { $in * 1_000_000_000 | into datetime }

# Option 2 - Works, just slightly more verbose
> $times | each { to text | into datetime -f '%s' }

# Option 3 (this PR)
> $times | each { into datetime -f '%s' }

In the last two cases, either way, it gets converted to a string. Either internally with this PR or manually by the user with | to text. Given that Unix epochs are so commonly stored as ints in dbs and APIs, it seems like a natural conversion to handle for the user.

You can also do 1722821463 * 1_000_000_000 | into datetime and it works fine because nushell wants int time stamps to be in nanoseconds.

Yup - Exactly. into datetime already handles int input when accepting a Nushell datetime in nanoseconds.

But if you want to specify a format string to do seconds (Unix epoch) instead of nanoseconds (without this PR) you get a (to me) unexpected refusal.

The question is, why does -f %s require a string?

Well, I don't have to convert to string internally. I could write a new match arm using from_timestamp, but that seems like it would be a waste when the existing match can just take the val.into_string() and re-use the same closure for both match arms.

The conversion here is just a DRY tool.

Right - Either way, it gets converted to a string here. Either internally with this PR or manually by the user with | to text. Given that Unix epochs are so commonly stored as ints in dbs and APIs, it seems like a natural conversion to handle for the user.

I don't understand what you mean here. date now | into int | into datetime isn't converted to a string anywhere, it's a date, then int, then date.

I've fine with your other answers but was confused by the above statement.

I've fine with your other answers but was confused by the above statement.

Yeah, apologies - I misread your example at first - I've edited the above based on what you actually said.

it's a date, then int, then date.

But using nanoseconds. To use an epoch, the int still requires some form of conversion.

thanks