* math is 0 based while ordinal is 1 based => fix as 1 based logic
* add extensive testing against the "date" command format
* format: test sample instead of every day
* 2007 starts with saturday
* Last day of the year is thus the 52 on Monday weekly calendar, 53 on Sunday weekly calendar.
* update %U expected value in test
* Was the goal was to have a different value than with %W at next line ? another date to pick ?
* update cfg("unix") into cfg(target_os = "linux")
* format tests/dateutils.rs
Currently CI is only run on changes to specific files. The list of these files incomplete and would
likely get outdated again if it were expanded. Exluding specific files would be a shorter, more
stable list.
However, the changelog is only kept for posterity and the readme has seen all of two commits in the
past three years that wouldn't have triggered CI by changing other files as well, so don't bother
and just run CI for any changed file.
`from_timestamp` and `Utc.timestamp` are deprecated, and have been replaced with `from_timestamp_opt` and `Utc.timestamp_opt` respectively, with unwrapping.
This previously called the `.datetime` field on the datetime, however this is problematic as it is in UTC time. It now correctly uses the `.naive_local()` method to get the local time as a NaiveTime
The limits on the secs count has to be hunted down to the bottom of
the readme / root document, which is a bit annoying when
e.g. migrating from the deprecated `from_timestamp` and wondering why
`from_timestamp_opt` is fallible.
The nsecs limits can be inferred from the rest of the text but
explicit is better than implicit.
We don't add `with_yo_and_hms()` and `with_isoywd_and_hms()` here,
instead recommending users can use `from_local_datetime()` with
a separately constructed `NaiveDateTime`.
