Update to crystal 0.25.0

[faustinoaq]

Minimally addresses issues required to update Granite to Crystal 0.25.0

• Update Dockerfile since crystal deps is being removed. CLI: remove deps command crystal-lang/crystal#5544
• Remove references of JSON::Type. Implement JSON::Any and YAML::Any without recursive aliases crystal-lang/crystal#5183
• File.stat is renamed to File.info Rename and rework File::Stat as File::Info crystal-lang/crystal#5584
• Update all instances of Time::Kind to use the new Time::Location instead

Read the changelog for anything I missed. https://github.com/bcardiff/crystal/blob/changelog/0.25.0/CHANGELOG.md

Fixes #226

[Blacksmoke16]

@faustinoaq We probably should also address other changes specified in #226.

[robacarp]

I believe this addresses all breaking changes for Granite to update to 0.25.

This represents a catastrophic breaking change for anyone using sqlite.

Sqlite, Mysql, Postgres all handle storing datetimes differently, and Crystal has changed the way it handles this stuff. Fun times.

The updates to the time code are basically:

• Standardize Granite on Granite::DATETIME_FORMAT where previously %F %X was scattered everywhere.
• Granite::DATETIME_FORMAT now includes a timezone offset: %F %X%z. Which means that times will now be rendered as '2018-06-15 12:19:58+00:00' instead of without the offset part.
• Most notably, timestamps stored in a sqlite database will not have the timezone and will throw an exception on read.
• Mysql returns a Time with a location of "local" instead of "unspecified". The mysql shard seems to have support for converting to UTC, but granite does not appear take advantage of this.
• Clean up a few tests.

cc @drujensen @damianham (I believe you've dealt with sqlite timestamps in the past?)

[drujensen]

@robacarp yes, I just disabled the timestamps to handle sqlite. It is a pita :-/

[drujensen]

nice change to Granite::DATETIME_FORMAT 💯

[damianham]

why not rescue the exception for existing time strings and try to parse with "%F %X" ?

[faustinoaq]

why not rescue the exception for existing time strings and try to parse with "%F %X" ?

Interesting idea, Would this solve the SQLite issue?

^^ @robacarp @drujensen

[drujensen]

I think this might work with one caveat:

We either need to store the time as UTC as a convention or we need to include the timezone in the stored string. You should always store the timezone implicitly or explicitly to get the right results.

I prefer we store the timezone in the string explicitly. The advantage is you can determine the timezone that was originally used by the client/server when it was originally stored. If you convert it to UTC before storing, you lose that information.

[robacarp]

I agree, it makes sense for Granite to store the timezone as provided in the Time object given. In the event that it makes more sense for an application timezone to always be UTC, the appdev can make that happen easy enough.