Pracowałem nad analizowaniem ciągów znaków i mam przypadek testowy, który powodował dla mnie problemy. Podczas analizowania łańcucha daty / czasu za pomocą strptime czas letni nie jest uwzględniany. O ile wiem, jest to błąd. Nie mogę znaleźć żadnych dokumentów w tym błędzie. Oto przypadek testowy w konsoli Rails. To jest ruby ​​1.9.3-p215 i 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>

Jak widać, muszę przekonwertować na utc, a następnie z powrotem na strefę czasową, aby poprawnie zinterpretować DST, ale wtedy czas jest również przesunięty o jedną godzinę, więc to nie jest to, co analizowałem z ciągu. Czy ktoś ma obejście tego błędu lub bardziej solidny sposób analizowania daty i czasu + strefy czasowej niezawodnie w obiekcie DateTime, w którym czas letni jest odpowiednio reprezentowany? Dziękuję Ci.

Edytuj: Ok, znalazłem obejście, chociaż nie jestem pewien, jak bardzo jest solidny.

Oto przykład:

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

Spowoduje to przeanalizowanie ciągu daty / godziny w prawidłowej strefie czasowej. Nie jestem pewien, jak solidna jest metoda analizowania tego problemu, więc chciałbym sprawdzić, czy istnieje lepsze obejście, ale jest to moja dotychczasowa metoda.