You can clone with
HTTPS or Subversion.
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.
Interesting, I'll take a look.
The problem is that when date is parsed by YAML and contains time, it will be represented by Time:
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.
Typecasting to String in it's turn returns date in local timezone.
Here's a simple example to better understand what's going on:
$ ruby -e 'require "yaml"; puts YAML.load("2012-12-31 23:30:00")'
2013-01-01 00:30:00 +0100
$ TZ=UTC ruby -e 'require "yaml"; puts YAML.load("2012-12-31 23:30:00")'
2012-12-31 23:30:00 +0000
$ TZ=America/Los_Angeles ruby -e 'require "yaml"; puts YAML.load("2012-12-31 23:30:00")'
2012-12-31 15:30:00 -0800
$ TZ=America/Los_Angeles ruby -e 'require "yaml"; puts YAML.load("2012-12-31 23:30:00 +02")'
2012-12-31 13:30:00 -0800
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.