Ich habe an der Analyse von Strings gearbeitet und einen Testfall, der mir Probleme bereitet hat. Wenn Sie eine Datums- / Uhrzeitzeichenfolge mit strptime analysieren, wird die Sommerzeit NICHT berücksichtigt. Soweit ich das beurteilen kann, ist dies ein Fehler. Ich kann keine Dokumente zu diesem Fehler finden. Hier ist ein Testfall in der Rails-Konsole. Dies ist Ruby 1.9.3-p215 und Rails 3.2.2.

<code>1.9.3-p125 :049 >   dt = DateTime.strptime("2012-04-15 10:00 Central Time (US & Canada)", "%Y-%m-%d %H:%M %Z")  
=> Sun, 15 Apr 2012 10:00:00 -0600  
1.9.3-p125 :050 > dt = DateTime.strptime("2012-04-15 10:00 Central Time (US & Canada)", "%Y-%m-%d %H:%M %Z").utc  
=> Sun, 15 Apr 2012 16:00:00 +0000  
1.9.3-p125 :051 > dt = DateTime.strptime("2012-04-15 10:00 Central Time (US & Canada)", "%Y-%m-%d %H:%M %Z").utc.in_time_zone("Central Time (US & Canada)")  
=> Sun, 15 Apr 2012 11:00:00 CDT -05:00  
</code>

Wie Sie sehen, muss ich in utc konvertieren und dann in die Zeitzone zurückkehren, damit die Sommerzeit richtig interpretiert wird, aber dann wird die Zeit auch um eine Stunde verschoben, sodass ich sie nicht aus der Zeichenfolge herausgeparst habe. Hat jemand eine Problemumgehung für diesen Fehler oder eine robustere Methode zum zuverlässigen Parsen von Datum + Zeit + Zeitzone in ein DateTime-Objekt, in dem die Sommerzeit ordnungsgemäß dargestellt wird? Vielen Dank.

Edit: Ok, ich habe eine Problemumgehung gefunden, obwohl ich nicht sicher bin, wie robust es ist.

Hier ist ein Beispiel:

<code>ActiveSupport::TimeZone["Central Time (US & Canada)"].parse "2012-04-15 10:00"  
</code>

Dadurch wird die Datums- / Uhrzeitzeichenfolge in die richtige Zeitzone analysiert. Ich bin mir nicht sicher, wie robust die Analysemethode dafür ist, daher würde ich gerne sehen, ob es eine bessere Problemumgehung gibt, aber dies ist bisher meine Methode.