I went on a rant about this inconsistency a while back. Not sure where that is but there's probably more than just what this PR does. Like, should format date be format datetime and what about Value::Date and Type::Date, should they be Value::DateTime and Type::DateTime? We already have Expr::DateTime. I'm sure there's more of this type of thing in the codebase.

I went on a rant about this inconsistency a while back. Not sure where that is but there's probably more than just what this PR does. Like, should format date be format datetime and what about Value::Date and Type::Date, should they be Value::DateTime and Type::DateTime? We already have Expr::DateTime. I'm sure there's more of this type of thing in the codebase.

i agree with this rant of yours, imo, as we only manipulate datetimes we should have datetimes not dates hanging out in Nushell 👍

maybe the only one that might lead to some friction is the date command because Bash has date and not datetime?
but maybe we could go with datetime now? 🤔

maybe we can go ahead with this PR which is a baby step in the direction of removing the inconsistency? 😋

maybe we can go ahead with this PR which is a baby step in the direction of removing the inconsistency? 😋

Nope, if the goal is consistency (at least in the user facing side) then a half baked PR is not the right thing to do.

You also missed nu-color-config/src/style_computer.rs that provides date as a type to style.

Everything that deals with the type/data representation and command names currently uses date. The odd one out is the parsing side with SyntaxShape with datetime. (Tangential rant that user definableSyntaxShapes should probably correspond to types at some point: looking at you path)

Thanks for proposing the PR. I think it's too old. And renaming this requires a larger change
I'm going to close it. If you think the change is still necessary, feel free to open a new PR.