hroptatyr/dateutils

dateseq range appears to have an incorrect interval

Earnestly opened this issue · 6 comments

When attempting to use dateseq to produce a list of days for a given month I've noticed it to include the last day of the prior month, for example:

% dateseq -i %m 09 1d 10
2021-08-31
2021-09-01
2021-09-02
2021-09-03
2021-09-04
2021-09-05
2021-09-06
2021-09-07
2021-09-08
2021-09-09
2021-09-10
2021-09-11
2021-09-12
2021-09-13
2021-09-14
2021-09-15
2021-09-16
2021-09-17
2021-09-18
2021-09-19
2021-09-20
2021-09-21
2021-09-22
2021-09-23
2021-09-24
2021-09-25
2021-09-26
2021-09-27
2021-09-28
2021-09-29
2021-09-30

I would have expected this to produce a range starting at 2021-09-01 and ending on 2021-09-30.

(Perhaps there is also an issue with how %m is defined in the manual as it claims to have a range from 00 to 19 but dateutils won't accept 19 as an input for %m. I should expect this to be 01-12 instead.)

I forgot to ask but is there a better way to generate a range like this? E.g. It would be nice if the following worked: dateseq now 1d +1mo or is it intended to use something along the lines of dateseq now 1d "$(dateadd now +1mo)"?

I have noticed that:

$ dateadd -i %m 09 1mo -1d
2021-09-29
$ dateadd -i %m 09 1mo
2021-10-00

Days seem to be off by one in a weird way.


EDIT: The day part of the date is initialised to 0 instead of 1. Is this intended?

$ dateadd -i %m 09 0d
2021-09-00
$ dateadd -i %m 09 1d
2021-09-01

Hi Emanuele,
thanks for the report. I agree about the documentation, %m is supposed to be in the range from 00 to 12, I shall fix that.

The other issue you're running in, are before-the-first-of-the-month dates. Examples include:

2021-09-00
2022-00-00

They exist so you can "assemble" a date:

$ dateadd 2022-00-00 +2mo +7d
2022-02-07

They obviously fail for negative summands in the way they are implemented now.

You tracked down the issue with dateseq correctly, it starts (because you only specify a month) on 2021-09-00. And dateseq fails to display the first result as such, instead 2021-08-31 (the true day before the first of the month in September) is printed.

This, too, is easily fixable. The bigger underlying problem of coming up with a sane set of rules for zeroed out dates remains (for now).

Surely it should be 01-12? I don't think it's reasonable to support 'zeroed out dates' in this manner and it's certainly not expected behaviour (at least for my locale).

I would never use -00-00 to assemble a date as you've demonstrated.

Well, you used the feature, in your initial dateseq call, by only specifying a month.

I didn't use 00. I used 09 is the correct month number for September, not 08 as it would be if months were zero indexed.