search

Tatoeba / tatoeba2

Tatoeba is a platform whose purpose is to create a collaborative and open dataset of sentences and their translations.
https://tatoeba.org
GNU Affero General Public License v3.0
714 stars 132 forks source link

Switching from daylight saving time messes up relative time records #478

Closed jiru closed 9 years ago

jiru commented 10 years ago

This has been observed on the 26 of October, 2014. Comments are also affected. Switching from DST makes you “jump in the past” so some dates appears to be in the future: -59 min(s) ago, -35 min(s) ago…

This happens because we store dates without the timezone they are relative to. Switching back/from DST means changing the time zone. This is how the time flows when DST ends:

$ date -Rud "26 Oct 2014 02:00:00 +0200" 
Sun, 26 Oct 2014 00:00:00 +0000
$ date -Rud "26 Oct 2014 02:59:00 +0200" 
Sun, 26 Oct 2014 00:59:00 +0000
# DST ended
$ date -Rud "26 Oct 2014 02:01:00 +0100" 
Sun, 26 Oct 2014 01:01:00 +0000
$ date -Rud "26 Oct 2014 02:59:00 +0100" 
Sun, 26 Oct 2014 01:59:00 +0000
$ date -Rud "26 Oct 2014 03:01:00 +0100" 
Sun, 26 Oct 2014 02:01:00 +0000
allan-simon commented 10 years ago

I think right now we generate the "ago" on server side, I think we can tackle two problems here at once by

1 - setting the server in UTC time, same for the date we save 2 - in the html pages, on server side ALWAYS generate the full time format in UTC time, and then use a javascript library to transform it into "ago" or local user time

this way it will both solve the DST problem , and it will permit to have less html changes, which will improve the "cache-ability" of the generated html

trang commented 9 years ago

Question 1: is there anything that we have to take care of, to prevent horrible things from happening, before changing the time?

Question 2: is it enough to do the following.

  1. Change the timezone to UTC in /etc/timezone
  2. Then ntpdate fr.pool.ntp.org
allan-simon commented 9 years ago

also change the php.ini i think

jiru commented 9 years ago

Question 1: is there anything that we have to take care of, to prevent horrible things from happening, before changing the time?

On the VM, changing the clock from UTC+1/2 to UTC+0 means going back to the past and repeating a timespan already spent. I don’t know if it’s dangerous on a server but I have a bad felling about it. What about rotating logs, active sessions…? Maybe a rebooting or shutting down the services is safer.

There is another problem I think it’s worth looking at. The clock of the host (as opposed to the VM) is misconfigured. It is set to 2 hours in the future. And so the VM is. We don’t strictly need to fix the clock of the host, but I suggest we do it while we’re tampering with the clock, so that we won’t have to do it after it eventually breaks things.

Question 2: is it enough to do the following.

  1. Change the timezone to UTC in /etc/timezone
  2. Then ntpdate fr.pool.ntp.org

Ntpdate will fix the clock on the VM regardless of the host. So fix the host first if you’d like to. I think the safer should be to shutdown the VM, run ntpdate on the host, start the VM, stop the services, fix the clock, start the services.

Finally, you also need to adjust the main index refresh time in sphinxsearch’s crontab (sudo -u sphinxsearch crontab -e). It’s currently shifted to +3 hours to match the correct time.

allan-simon commented 9 years ago

note that going back to the past , at least for PHP is what is already happening as it's the very reason of the bug. It happened twice a year , every year and no one is dead.

trang commented 9 years ago

I've written a more detailed procedure below (not sure about the exact commands for starting/shutting down the services).

Is there something missing or incorrect?

1. Shut down the VM

2. Change time on the host

3. Change time on the VM

loolmeh commented 9 years ago

the right ini file to edit is /etc/php5/fpm/php.ini I think it's working now, will take an hour for the negative minutes count to normalize