In the YAML header, for the date field, you should really consider using, by default, a standard format, such as: YYYY-MM-DD hh:mm:ss
The format I proposed above was inspired by the ISO 8601 standard: http://en.wikipedia.org/wiki/ISO_8601
The current format “MM/DD/YYYY” makes no sense to, e.g., many European countries where, when “/” are specified, have this format: DD/MM/YYYY.
You an use whatever date format you like in the date field of the page header. The blog skeleton just happens to have this US-style readable date to show that you can do it.
However, you can store it however you wish as long as PHP can determine it’s a valid date. ISO 8601) is fine to use too.
You can also change the format of the date on render with the Twig Date filter
In the documentation there is reference to American style vs European style, but you state you can have whatever format. I’m running into an issue where I have the reference ISO format (YYYY-MM-DD HH:MM:SS) and it displays incorrectly.
I’m not sure how best to address (without changing the input data, which I would rather not do).
Thanks for any pointers.
Discovered that the results are different if the date field(s) are enclosed in double-quotes (") - “YYYY-MM-DD HH:MM:SS” seems to be working for me.
Just adding the note in case somebody else happens by.
Can’t we set the default format to be ISO 8601? I’m sorry, but this standard of US style using
/ and European style using
- is no standard at all. Both characters,
-, are used on both date formats. Specially when having a multi language team of writers, this can cause a big confusion. The only really international standard of date I know about is ISO 8601. I saw that we can use quotation marks to “enable” it, but this is too open to user errors.
ISO 8601 also have several advantages. Going a little off, for example, it would be really useful to use dates to order entries on file system:
You could write a plugin to do this if you wished. I think it would only confuse things more for people if it were in the core.
Thank you for your attention, @rhukster.