New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time passed as string to template when specified in front matter #119

Closed
akdh opened this Issue Jan 14, 2010 · 4 comments

Comments

Projects
None yet
4 participants
@akdh

akdh commented Jan 14, 2010

A time specified in the front matter eg. date: 2010-01-10 13:07:09 will get passed to liquid as a String instead of a Time object. This causes the custom date filters in liquid to fail.

akdh/jekyll@e3b1ab5 fixes this issue by passing the object that jekyll parses to liquid instead.

Not that without this change times with timezones are fine, eg. date: 2010-01-10 13:07:09 -08:00. Dates without times are also fine, eg. date: 2010-01-10. But I saw in the 2010-01-09-time-override.textile test post that jekyll supports the non-timezone format.

The non-custom (liquid core) date filters do not fail if passed a String because they check the object type. This could also be done in jekyll.

@mojombo

This comment has been minimized.

Contributor

mojombo commented Jan 14, 2010

The YAML data needs to override the calculated data which is why the merge is done in the direction it is. I think it would be better to follow the convention that Liquid uses and have Jekyll's date filters take strings as inputs.

@akdh

This comment has been minimized.

akdh commented Jan 14, 2010

Ah, yes of course, that makes more sense.

@krisb

This comment has been minimized.

Contributor

krisb commented Jan 16, 2010

This affects more than just the date field. If you supply tags as a string then the tags would also be replaced by the string version on calling to_liquid.

I've created a branch to explore this further and show the tests of what is expected.
http://github.com/krisb/jekyll/tree/issue_119

Another approach would be to delete any entries in the data hash on initialize and preserve the existing payload generation logic.

Site, Page and Post payload generation should be the same really. Note that Site overrides config data such as the time which is the reverse in logic to the way Post works where data overrides attributes. Page really doesn't go in either direction as it only provides the data it is given with no additional attributes.

@mojombo

This comment has been minimized.

Contributor

mojombo commented Jun 19, 2010

Merged krisb's patch in master.

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.