Skip to content
Browse files

Quote these dates to prevent intermittent test failure. Suppose local…

… time is 00:50 GMT+1. Without the quoting, the YAML parser would parse this as 00:50 UTC, into the local time of 01:50 GMT+1. Then, it would get written into the database in local time as 01:50. When it came back out the UTC date from the database and the UTC date of two weeks ago would be compared. The former would be 23:50, and the latter would be 00:50, so the two dates would differ, causing the assertion to fail. Quoting it prevents the YAML parser from getting involved.
  • Loading branch information...
1 parent 7d43217 commit f000d4e5faeabafece59a46911a74e876785b785 @jonleighton jonleighton committed Aug 4, 2011
Showing with 4 additions and 4 deletions.
  1. +2 −2 activerecord/test/cases/fixtures_test.rb
  2. +2 −2 activerecord/test/fixtures/pirates.yml
View
4 activerecord/test/cases/fixtures_test.rb
@@ -587,8 +587,8 @@ def test_only_populates_columns_that_exist
end
def test_preserves_existing_fixture_data
- assert_equal(2.weeks.ago.utc.to_date, pirates(:redbeard).created_on.utc.to_date)
- assert_equal(2.weeks.ago.utc.to_date, pirates(:redbeard).updated_on.utc.to_date)
+ assert_equal(2.weeks.ago.to_date, pirates(:redbeard).created_on.to_date)
+ assert_equal(2.weeks.ago.to_date, pirates(:redbeard).updated_on.to_date)
end
def test_generates_unique_ids
View
4 activerecord/test/fixtures/pirates.yml
@@ -5,5 +5,5 @@ blackbeard:
redbeard:
catchphrase: "Avast!"
parrot: louis
- created_on: <%= 2.weeks.ago.to_s(:db) %>
- updated_on: <%= 2.weeks.ago.to_s(:db) %>
+ created_on: "<%= 2.weeks.ago.to_s(:db) %>"
+ updated_on: "<%= 2.weeks.ago.to_s(:db) %>"

8 comments on commit f000d4e

@jonleighton
Ruby on Rails member

@tenderlove I guess there is a question of whether we ought to support this without quoting - i.e. to prevent YAML from parsing it as a date. What do you think?

@tenderlove
Ruby on Rails member

Yes, we have to. It's very common to use the date without quotes. TBH, this sounds like a bug in the YAML parser. Can you write a test that would show exercise the problem with YAML? If local time is 00:50 GMT+1, then it should be parsed the same way.

@jonleighton
Ruby on Rails member

The thing is, the above outputs the date as "YYYY-MM-DD HH:MM". No time zone.

In the absence of a time zone, YAML assumes GMT (see the spec). But the date is actually output as GMT+1 (say). Hence the problem.

I have created a bug for this: #2427. (In fairness, this doesn't appear to be a regression, so I whilst a fix would be nice, it doesn't seem urgent to me.)

@jonleighton
Ruby on Rails member

Just to add - this won't be a problem when people have default_timezone set to UTC rather than local, which most people will.

@tenderlove
Ruby on Rails member

Why don't we make to_s(:db) output the timezone?

@jonleighton
Ruby on Rails member

Because different databases deal with time zones differently and may or may not support including the time zone.

@tenderlove
Ruby on Rails member

@jonleighton I have a doubt. Isn't this why we have ISO date formats?

@jonleighton
Ruby on Rails member

AFAIK only postgres supports a timestamp type which includes a time zone (and you have to specifically use that type, as opposed to the default which does not include a timezone).

See https://gist.github.com/9cff3986c396eecf6374, which indicates that mysql and postgres will ignore any added timestamp portion, and sqlite3 will not complain but not interpret it as a valid date either.

If I'm missing something, do tell :)

Please sign in to comment.
Something went wrong with that request. Please try again.