Note that there are some explanatory texts on larger screens.

plurals
  1. POActiveRecord's weird timezone handling when Daylight Saving Time changes
    text
    copied!<p>I have an application providing agenda functionalities.</p> <p><em>Disclaimer: I really love Rails and AR's functionalities, this is just meant to ask how can I exploit it functionalities better the next time.</em></p> <p>Since it has to be used by a european team it has been developed using +0200 timing informations. I know that the timezone stuff is handled by AR and the base data is always stored in UTC.</p> <p>The issue I get (but I already solved, just wanted to get some feedback to think it better the next time) is that when I store a new appointment I also enforce "+0200" at the end of the <code>DateTime.parse</code> call (es. <code>DateTime.parse("#{day} #{hour} +0200")</code> and then I set it as record attribute. Of course <code>10:00</code> gets stored as <code>08:00</code> inside the data layer, and that's fine.</p> <p>Then when I retrieve that data using the configured AR timezone (<code>Rome</code> for instance) using something like <code>@appointment.start_at</code> it correctly gets converted back when we are under the CEST daylight time. Issues start happening when <code>start_at</code> are set to be CET (+0100) dates (but I always store it inside the database enforcing CEST +0200).</p> <p>Inside the database <code>start_at</code> is always the same, so the UTC representation is always <code>08:00</code> when saving an appointment with <code>10:00</code> but the AR conversion uses the wrong daylight conversion (CET).</p> <p>I know I could skip this by simply working all on UTC so I don't have to carry out any consideration about daylight savings times, but it seems a bit messy that AR itself is not able to remember somehow that I stored it while CEST is running.</p> <p>When performing queries I do the same as when storing, so I append "+0200" to all DateTimes, and all works back again, but when displaying I need to check whether the TimeZone is "CET" or "CEST" and add a <code>+1.hour</code> to CET (otherwise it results the appointment has been signed 1 hour before than the intended hour).</p> <ol> <li>Is it right I should handle this by myself?</li> <li>Shouldn't be AR able to perform this kind of check since it wraps the data-layer?</li> <li>How should I design an application the next time to avoid this kind of issue while still using local timezones? (as I said using UTC may also not be applicable by some requirements)</li> </ol> <p>I thought I should change "+0200" with "in_time_zone" the next time, but I also allow users to write by hand an hour to search, and of course this will always be the same time either it is "CET" or "CEST" and of course I cannot enforce users to write following the UTC format.</p> <p>Thank you,</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload