ISO8601DateFormatter

[dpfannenstiel]

As a web site developer I want to support time zone within my posts without having to write a custom date formatter. The default date formatter has support for the format "yyyy-MM-dd HH:mm", which ignores time zone.

In Publish 0.5.0 date formatting is handled via the DateFormatter class, which conforms to the Formatter protocol. Along with the many fine date formats there exists ISO 8601, which the Foundation framework implements in the ISO8601DateFormatter class, which also conforms to the Formatter protocol. Since PublishingContext requires a DateFormatter I cannot use ISO8601DateFormatter.

This pull request makes two changes.

First, it introduces AnyDateFormatter, a minimal protocol to define a common interface for date formatters to conform. Most of the API is already implemented by DateFormatter and ISO8601DateFormatter, so implementing the protocol as an extension is trivial.

Second, PublishingContext changes dateFormatter to a AnyDateFormatter and then make any subsequent changes to support that type change. As part of this change, the default dateFormatter value is set to a ISO8601DateFormatter. This will result in a breaking change for existing users of Publish, but it is believed that using a well known date format represents a common initial case.

[john-mueller]

I think the addition of AnyDateFormatter and ISO 8601 compatibility make sense. I don't think making it the default is the best option, however, as I think most people would rather use the current default "2020-03-12 15:00", as opposed to "2020-03-12T15:00:00-06:00".

You could use ISO 8601 with a custom step:

.step(named: "Use ISO8601DateFormatter") { context in
    if #available(OSX 10.12, *) {
        context.dateFormatter = ISO8601DateFormatter()
    }
}

It's probably worth adding that to Documentation/HowTo/using-a-custom-date-formatter.md.

[dpfannenstiel]

I've updated the PR with better documentation on AnyDateFormatter.

My thoughts regarding the default date formatter are based around standards. ISO 8601 has really wide adoption, whereas the current default is pretty custom and doesn't handle timezone at all. I don't know what the roadmap to 1.0 looks like, but thinking about onboarding a new user you want to give them the minimum amount of friction to deployment. So I guess it becomes a question of how important is time zone localization to a mature product for deployment.

[addisonwebb]

This is something I would love to have merged. Is there any way I can help out with this @dpfannenstiel?

[dpfannenstiel]

@addisonwebb I’m trying to get @JohnSundell thoughts on how to include the AnyDateFormatter. Digging around I had found a version of it in a support library. But modifications are required. I’m not a huge fan of duplicating code needlessly and Codextended seems like the place to do it.

[addisonwebb]

Ok @dpfannenstiel @JohnSundell I have submitted 2 PRs to address this issue using the existing AnyDateFormatter in Codextended.

• Codextended PR #15
• Publish PR #109

These should be the minimal changes necessary to allow Publish users to use both DateFormatter and ISO8601DateFormatter as the custom date formatter on the publishing context. No breaking changes are introduced by these changes.