Time Zones are political things, and move. The timezone database knows
this, and correctly interprets times as they would have been at the
time.
For example, when the Time zone is Africa/Monrovia, the offset now is
0, but the offset in 1970 was -44.5 minutes, so Time.zone.at(0) is Dec
31st, 1969, 23:15:30 and not Jan 1st, 1970 00:00:00.
Prevent this spec from randomly failing based on Zonebie's selected
timezone by comparing the offset _then_ against UTC, and predicting
whether the 60's have ended yet.
* Maybe this is what we need to do?
* Undo change to keyword
Use the on_html translation in the view, but pass 'on' as a keyword to
the template.
* remove unused translation
Since we only want to use views.articles.crossposted.on.html (and this is only used in the
article show template) - remove the unused 'on' key from the
translations file.
* Add a spec
Tested that this fails in main and passes on the branch
* Check that the original publication date is shown in the users local
And that it's not a <time> tag presented as text
* Correct local date selection error
If time zone was UTC (i.e. offset from utc was 0) the check for
positive? was false, I meant "non-negative" (positive or zero). Invert
the test.
* Show canonical URL on article even after it has been updated
* Refactor canonical URL fix
* Clean up canonical URL code
* Clean up canonical URL code
* Initial automatic cleanup with rubocop
* Fix syntax error introduced by rubocop
* Cleanup seeds file
* Cleanup lib folder
* Exclude bin folder because it contains auto generated files
* Make Rubocop a little bit more chatty
* Block length should not include comments in the count
* Cleanup config folder
* Cleanup specs
* Updated Rubocop version and generated a todo file
* Fix broken ArticlesApi spec
* Fix tests
* Restored rubocop pre-commit hook
