-
-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Test cases assume they're not being run in Sydney #698
Comments
Interesting, I'll take a look. |
The problem is that when date is parsed by YAML and contains time, it will be represented by YAML.load('2012-12-25').is_a? Date # => true
YAML.load('2012-12-25 10:00:00').is_a? Time # => true So when it reads this date and it contains not TZ, it assumes UTC. Here's a simple example to better understand what's going on:
|
I think the easiest way to deal with this (without "fixing" YAML.load) is to have dates in the YAML front matter be strings by quoting them. Then, YAML.load gives you a string that you can attempt to parse more flexibly in lib/jekyll/post.rb. It wouldn't be too hard to write something up to recognize a properly formatted date like iso8601 or rfc2822 and generate a Time object with the offset specified. The problem is the inconsistent behavior based on whether the date is quoted or not. I'd also like to see the TZInfo library used so the times could be overridden to always be in a configured timezone. This is something I could code up and do a pull request for, but I'm not sure what the preferred direction would be. |
Seems to be a duplicate of #850. Closing. |
I ran the test suite for version 0.12.0 and got these failures:
In all three cases, the problem seems to be that a time in YAML Front Matter is being parsed as UTC and then formatted as a string using the system's time zone – UTC+11 for me – while the subsequent assertions assume that the system's time zone is closer to UTC.
The text was updated successfully, but these errors were encountered: