Data.Time.Calendar.Days has a narrow range around 1864

[Warbo]

The current behaviour seems a bit weird and unuseful: it calls ModifiedJulianDay with an Integer generator (2000 +) <$> arbitrary. The haddock of that function states:

The Modified Julian Day is a standard count of days, with zero being the day 1858-11-17.

The arbitrary @Integer generator is bounded by +/- the current size, which defaults to 100 in QuickCheck, HSpec, etc. Adding 2000 gives a default range of 1900 to 2100 days after 1858-11-17; which is 1864-01-30 to 1864-08-17. This range seems quite obscure to me: it doesn't seem to contain anything significant, whilst it excludes many potentially-useful days (e.g. 1858-11-17 itself; the UNIX epoch 1970-01-01; the millenium bug 2000-01-01; the BCE/CE epoch 0000-01-01; the 2038-01-19 epochalypse, etc.). In fact, the addition of 2000 is specifically preventing the 1858-11-17 epoch appearing.

My guess is that the current behaviour is due to a mix up between days and years: it would make a lot of sense to give (2000 +) <$> arbitrary to a hypothetical makeCEYear function, to get a range of years which are realistic, symmetric, centered on the round number 2000, and default to include the current and previous centuries. Yet that's not at all how ModifiedJulianDay behaves!

I'm not sure of the best alternative, hence I haven't made a PR yet. Here are some ideas:

Revert to previous behaviour: it was changed in 2012 in commit ceb3def. The previous behaviour was this:

Time.ModifiedJulianDay <$> choose (gregToNum 1200 1 1, gregToNum 2999 1 1)

Where gregToNum was a custom function which that commit also deleted. This seems to produce days between 1200-01-01 and 2999-01-01, which seem like reasonable bounds. However, there's no dependence on size, and no natural "origin" for small values (although the shrinker added by commit ceb3def will drag them towards 1858-11-17 afterwards).

"Fix" the addition: based on my guess above about the intended behaviour, we can change + 2000 to + 51544. That will generate days symmetrically around 2000-01-01, based on the size parameter. However, that magic number feels a bit hacky; and it doesn't correspond to the shrinking behaviour.

Use Integer unmodified: don't add any offset to the generated days. This behaviour is simple, corresponds well to the data model, and to the existing shrinker. However, the default range will remain quite small and unrealistic (between 1858-08-09 and 1859-02-25).

Use Integer scaled: don't add any offset, but scale the arbitrary @Integer generator to a more realistic range; for example, ModifiedJulianDay <$> scale (* 1000) arbitrary will give a default range from 1585-02-01 to 2132-09-01, which seems reasonable. Since Integer is unbounded this seems fine for any sensible value of maxSize. This is my preferred option.

---

Note that I discovered this while deleting a bunch of custom Arbitrary instances from a project that has quickcheck-instances as a dependency ("Why are we bothering to define our own?", I thought). Whilst most of the Time instances were basically the same as quickcheck-instances (hours from 0-23, minutes from 0-59, etc.) its Day instance uses choose (0, 100000), which covers a much more useful range. Annoyingly, I can't import the Time module from quickcheck-instances whilst keeping that useful instance for Day. Hence it would be nice to fix this upstream!

[Warbo]

Looks like this is already addressed by #13