Rails Ruby on Rails

Comments and changes to this ticket

• You flagged this item as spam.
  

  jufemaiz March 9th, 2010 @ 11:27 AM

  I don't believe that this is an issue. If you look at the chaining for DateTime.parse('2009-01-05 23:12:11 CET').beginning_of_year.utc

  DateTime is parsing a date, then giving the beginning of that year (in local time). The returned date is then transformed to UTC.

  Resolving your issue would be more likely to apply the UTC first and work from a UTC perspective.

• 

  Geoff Buesing March 9th, 2010 @ 02:06 PM

  • State changed from “new” to “invalid”

  Indeed, this isn't an issue, you're just coming across a limitation of the DateTime class.

  The DateTime class doesn't have any knowledge of daylight savings time, unfortunately, which means that DateTime#beginning_of_year won't be able to adjust for that. In other words, DateTime#beginning_of_year will preserve the local offset of the DateTime instance it's called on, and just change the date and time values. That's the best we can do with the information given.

  DateTime.parse does have a limited understanding of time zones -- it understands that "CET" represents a +0100 offset in the beginning of the year, and that "CEST" represents a +0200 offset. But this is a very naive implementation:

  >> DateTime.parse('2009-01-05 23:12:11 CET')
  => Mon, 05 Jan 2009 23:12:11 +0100
  >> DateTime.parse('2009-01-05 23:12:11 CEST')
  => Mon, 05 Jan 2009 23:12:11 +0200
  

  ... I can force Jan 5 to be CEST, even though that's not correct.

  Best if you avoid DateTime.parse, unless you really want an instance of DateTime. If you need to parse a time from a string, and you know which time zone this time needs to be in, you can use TimeZone.parse:

  >> Time.zone = 'Paris'
  => "Paris"
  >> Time.zone.parse '2009-06-05 23:12:11'
  => Fri, 05 Jun 2009 23:12:11 CEST +02:00
  >> Time.zone.parse('2009-06-05 23:12:11').beginning_of_year
  => Thu, 01 Jan 2009 00:00:00 CET +01:00
  

  Time.parse has the unfortunate behavior of interpreting nonsense as Time.now, which makes it pretty much unusable:

  >> Time.parse 'no time here'
  => Tue Mar 09 08:04:31 -0600 2010
  

  ... which is probably why you're using DateTime.parse. (Time.zone.parse doesn't do this, fyi.)

• You flagged this item as spam.
  

  Christian Weyer March 9th, 2010 @ 02:18 PM

  I found a a way around this problem in the meantime as well, but I still think that the time span calculators should care about if the timezone needs to adjusted. Without that, the time zone support seems incomplete to me, or at least the documentation should make it very clear, that DST crossing time spans will be computed incorrectly. Otherwise people (like me) may assume rails time zone support works even in this more "difficult" cases.