Replace Time::Piece with DateTime

[preaction]

The Time::Piece module is based on the tm struct of the underlying OS. This can result in complications, including an inability to parse date/time before 1900-01-01.

The DateTime module can correctly express dates and times in any range. It is pure-Perl, so easily installed. Instead of using Time::Piece, we should switch to DateTime for our internal date representations.

This may be a breaking change. Worse, it may be a breaking change in the templates, since some templates require the use of formatted date and time. If this is a breaking change, if possible, we should try to smooth the process with a wrapper class (like Statocles::DateTime or something).

[kentfredric]

I'd probably discourage DateTime to some extent, as it has some API choices that can't be removed and are footguns.

https://rjbs.manxome.org/rubric/entry/1929
http://blog.plover.com/prog/perl/DateTime-Moonpig.html
https://metacpan.org/pod/DateTime::Moonpig

Or something similarly sensible would be recommended.

[preaction]

Yeah, but DateTime::Format::Strptime doesn't make DateTime::Moonpig objects... DateTime::Tiny can't format. Date::Parse suffers the same bug as Time::Piece. Is there something simple and not terrible that can strftime and strptime and support an encyclopedia of dates?

I'm of the opinion that only ISO8601 dates should be accepted as input by Statocles, and that's easy enough to parse, so I think I'll try getting DateTime::Moonpig objects in there. It's only an accident of history that we have to output other date formats (RSS uses RFC822 dates, why?).

[preaction]

DateTime::Moonpig / DateTime do not have the tzoffset method. Instead they have a better offset method. This requires changing the feed templates. Anyone who upgrades will get exceptions about a missing tzoffset method.

[preaction]

I could install a DateTime::Moonpig::tzoffset method as a temporary measure (warning when it is used) to smooth the transition...