Month handling is broken for date patterns that don't include a day, in timezones with a negative offset

[sruggier]

Hi! Greetings from Canada, and thanks for all of the work you've done on this project. I hit a problem related to my local timezone, which will only affect users in the western hemisphere who try to configure patterns that don't capture a day of month. In particular, with this kind of pattern, adding to a month skips over months that have less than 31 days, while subtracting only lands on the expected month if it has 31 days.

I did some investigation and found that this line uses the epoch as a default to fill in all fields, but on systems where the local timezone has a negative offset, the date used to populate the return value will be formatted like so:

$ date --date='@0'
Wed 31 Dec 1969 07:00:00 PM EST

That formatting behaviour causes dt_info to default to the 31st of the month. With the dt_info.day containing 31 by default, attempts to configure augends with patterns like year/month (patterns that don't capture a day of month) result in the weird behaviour described above.

An augend like one of these can reproduce the behaviour, but only if the user's local timezone has a negative offset:

          augend.date.new({
            pattern = "%Y-%m",
            default_kind = "month",
            only_valid = false,
            word = true,
          }),
          augend.date.new({
            pattern = "%Y/%m",
            default_kind = "month",
            only_valid = false,
            word = true,
          }),

If I understand correctly, the bug can be fixed with minimal effort, by asking date to ignore the local timezone, like so:

    local dt_info = os.date("!*t", 0) --[[@as osdate]]

I've made a PR that fixes the problem, and tested it on my system.