Should cobalt use the native yml date/time format

[epage]

See the spec.

It looks like Jekyll advertises a specific flavor.

[epage]

While frontmatter is yml.,

• _data can also be toml (similar but probably not same as yml) or json (no time format)
• We also need to consider what format is "native" to liquid.

[epage]

RE Liquid

The main use case I find is the date filter

• date filter calls
• Utils.to_date
  • If already a date time, no need to parse
  • If looks like an integer, parse as timestamp
  • If looks like a string, downcase and use Time.parse which is implemented by date__parse (upstream without syntax highlighting).
    • This supports a lot of different formats, subsets, etc.

[epage]

The commit that cobalt's format was introduced in doesn't provide much reasoning

8bd0722

[epage]

So summary of my thoughts

• Use a format that is cross-format (ie not yml specific)
• We should make the time portion optional, like Jekyll
• Main contenders would be the current format (28 December 2017 15:45:10 +0800) or Jekyll's (2017-12-28 15:45:10 +0800).

[epage]

irb(main):003:0> Time.parse("05 December 2017 15:23:00 +0800")
=> 2017-12-05 15:23:00 +0800

Looks like Time.parse supports our format, therefore the date filter should support it, therefore we know it doesn't conflict with other potential date formats to parse in Ruby's complex parse function, therefore the existing format is future compatible.

[Geobert]

Let's support them all? give some flexibility to the user.

If optional, when sorting by order, do we put them at the beginning or the end (atm, we fallback to beginning of time)

I like the Jekyll's format best, I don't like having the month fully written ^^'

[epage]

The date filter should support a variety of inputs because the source of the data can be a lot of different things (and because the official version of liquid does it).

I don't see much value in supporting multiple formats in the frontmatter. This is data written by the user specifically for cobalt. We'd need to document the choices which adds noise to the documentation. I've been working to make cobalt opinionated in things that people should have no reason to change (like names of the _ prefixed directories) while keeping it flexible for a lot of other things.

[Geobert]

I see, I didn't think of the documentation aspect, you're totally right :)