Fix date offset for visitors far from the UTC timezone

[fpagnoux]

If I visit the legislation explorer at a time and from a timezone where the date is not the same one that in the UTC timezone, there is an offset in all the dates.

This is harder to see from France (except from 11pm to midnight), but probably more problematic for Aotearoa-NZ.

Before, at 6PM EST:

After, at 6PM EST:

[Br3nda]

This leads me to the question: When we supply dates, we probably need to supply them in UTC - which is ambigious without a time attached.. We are currently 13 hours ahead of UTC.

It's all a bit murky for date-of-birth, given we consider someone to be a year older once their birthday has occurred in New Zealand, even if they were born in France or Alaska.

[Morendil]

@fpagnoux You can pass a timeZone to the IntlProvider instead - locate the decision in one place rather than four.

[Morendil]

@Br3nda Oh… so a legal "date of birth" is not a DateTime in the programmer sense. That's probably listed somewhere in there. ;)

More seriously: we actually have a related issue in the France model, where even without timezone offsets we had off-by-one errors in age calculations. I checked what concept of "age" the law uses and it matched your description above, you're considered a year older right after the clock ticks over on the date of your birth. So what would seem to matter is "local midnight". If a birth date input variable is specified without a time (which is what I'd expect), the conversion to a full datetime should do the right thing, i.e. convert both dates to datetimes at local midnight.

It's interesting that your formulation of age looks quite different from the one in France…

[fpagnoux]

Sorry, the code is confusing, and I didn't provide enough elements.

This PR by no means intend to ask users to provide any date in UTC 🙂

The current issue is the following:

• So far, in OpenFisca, we don't worry about timezones. All legislation we have encountered so far only use dates with at most a one-day precision.
• Therefore, the dates we format in the legislation explorer look like "2017-06-01". No specific time or timezone is specified, as we don't seem to need this concept.
• However, when we ask react-intl to format these dates, it assumes that "2017-06-01" means June 1st 2017 at midnight in the UTC timezone. Which is 2017-05-31 is, for instance, the EST timezone.
• Now, when a user visits the legislation explorer, react-intl by default format dates in their local timezone. This behavior is irrelevant: if I look at the NZ legislation from the US, I don't want my timezone to have any influence.

Now, to fix this issue, this PR suggests to ignore local timezones, and to format all dates in UTC. But that doesn't actually impose UTC on any country: it just enforces that, in the legislation explorer, react-int parses and format dates in the same timezone. This guarantees that there will be no offset, and that dates will always be formatted as they are defined in the legislation.

The alternative would indeed be to

• Define a time (hh:mm) and a timezone for all dates in OpenFisca, the timezone being probably set at the country-package level.
• Format all dates according to the country package's timezone

This is a lot of complex stuff for the exact same behavior! Unless we encounter use cases where specific time and timezones matter, I'd much rather prefer keeping things simple and just fix this formatting issue