I haven't looked at the code yet but I'm wondering if --days and --period should be mutually exclusive instead of --days just being silently ignored, as you describe above. I'm not a huge fan of ignoring flags and not telling people what's going on. It tends to lead to problems.

This is a very cool addition. I really like it alot. Thanks for working on it!

Maybe the best solution is just to remove --days. Its original purpose was to set the number of elements in the output when only one of --begin-date or --end-date was set, which is what --periods tries to do but with an argument name that applies more generally.

The --days argument does behave slightly differently from --periods when --increment is not 1day. For example,

# OLD BEHAVIOR (using --days)
> seq date -b 2025-01-01 --days 5 --increment 2
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-03 │
│ 2 │ 2025-01-05 │
╰───┴────────────╯

# NEW BEHAVIOR (using --periods)
> seq date -b 2025-01-01 --periods 5 --increment 2day
╭───┬────────────╮
│ 0 │ 2025-01-01 │
│ 1 │ 2025-01-03 │
│ 2 │ 2025-01-05 │
│ 3 │ 2025-01-07 │
│ 4 │ 2025-01-09 │
╰───┴────────────╯

I suspect --days isn't being used much in the wild anyway, given it has an off-by-one error.

I guess I'm ok with removing --days. I really don't like breaking changes but --periods seems a better fit with these changes.

Another alternative is to move this logic into a separate command, seq datetime? This may introduce some command-bloat and is not my preference, but it will mitigate breaking changes. Just a thought.

I'd rather just have it all in seq date because it's easier to type. Just my opinion.

I honestly think we should be going in the direction of using Value::Date here, I don't think there's any advantage to using strings. If you want a specific output format, you can always tack on a format date to format the dates however you'd like. I don't love that we're duplicating datetime parsing logic here. Especially if we're making breaking changes, I think it would make sense to switch over to using actual dates instead of strings. I don't mean to force this all onto you in this PR, but I do think if we're making breaking changes we should rip off the band-aid here and super-break it once instead of breaking it twice.

Agreed. I wanted to switch to SyntaxType::DateTime types for begin and end dates, and DateTime for the outputs, but also wanted to minimize the scope of breaking changes in this PR. Happy to implement it if there's more buy-in. @fdncred, any thoughts here?

I think we save the datetime changes for another PR. I'm not necessarily against it, although it makes getting an answer more difficult because you have to tack on a format command.

maybe then we avoid breaking anything with this PR, merge it now/before release, and then do all of the breaking in another PR?

I think the only way to have no breaking changes is to overload the --increment argument to accept both an integer and duration. Definitely doable -- whether that's preferred, I'm not sure.

I'm fine with @132ikl's suggestion of having this be a non-breaking change for now.

I think the only way to have no breaking changes is to overload the --increment argument to accept both an integer and duration. Definitely doable -- whether that's preferred, I'm not sure.

maybe not ideal, but I think this is a reasonable tradeoff, as long as we do follow up at some point

See updated PR: breaking change has been mitigated, and --increment now accepts either integer or duration. All default values are the same, and all previous commands run as expected.

Thanks