5

I have purchased a CentOS 6.8 dedicated server to migrate from shared hosting, and I'm having trouble with the time zones not displaying properly.

I have changed the php.ini time zone to Europe/Dublin - it didn't work

I have changed the httpd.conf timezone to Europe/Dublin - it didn't work

And I am trying to change the actual CentOS timezone and this is where it gets weird. I changed time zone to Europe/Dublin from CST (which was the default), and it seems to think that Europe/Dublin is GMT+14.

Please see the image link below. The second date should have said Sat Jan 7 07:48:11 GMT 2017.

Weird server time zone situation

Improve this question
4
  • 4
    In the future, please copy-paste the text from the terminal rather than a screenshot of it.
    – janos
    Commented Jan 7, 2017 at 7:57
  • One of the goto commands for NTP is ntpq -p which prints out the current variance from the configured NTP servers. This can be helpful.
    – Criggie
    Commented Jan 7, 2017 at 19:47
  • Your time zone is correct; it is your time that is wrong.
    – Michael Hampton
    Commented Jan 7, 2017 at 20:26
  • @MichaelHampton we figured that out just after you went to bed ;)
    – user9517
    Commented Jan 7, 2017 at 21:28

3 Answers 3

Reset to default
10

The CST time zone is GMT -6, so if CST time is 15:47 then GMT time is 21:47.

If you are saying that at the time you took the screenshot the time was supposed to be 07:48 in the morning, then your server time is not correct, and you need to synchronise it.

Run this command to synchronise the time to correct one:

ntpdate -s time.nist.gov

It is possible you don't have ntp installed at all on your server, in which case you need to install it with:

yum install ntp ntpdate ntp-doc

And start the NTP service to keep the time synchronised with:

/etc/init.d/ntpd start

Also make sure to set the NTP service to autostart on boot with:

chkconfig ntpd on
Improve this answer
0
5

I think the underlying problem is that "CST" is an ambiguous name for a timezone. It can stand for Central Standard Time, China Standard Time, and Cuba Standard Time.

[me@risby ~]$ export TZ=GMT ; date
Sat  7 Jan 09:21:31 GMT 2017
[me@risby ~]$ export TZ=US/Central ; date
Sat  7 Jan 03:21:31 CST 2017
[me@risby ~]$ export TZ=ROC ; date
Sat  7 Jan 17:21:31 CST 2017
[me@risby ~]$ export TZ=America/Havana ; date
Sat  7 Jan 04:21:31 CST 2017

(I'm aware that the ROC is not the PRC, but they keep the same time, and I can't immediately put my hand on an unambiguously PRC-specific timezone in my /usr/share/zoneinfo.)

So I suspect you're thinking that your system clock is in China Standard Time, and thus expecting GMT to be eight hours behind that (0748GMT), whereas my guess would be that it is in Central Standard Time, which puts GMT six hours ahead of that (2148GMT). The latter interpretation is consistent with what you've shown us.

So set your system timezone to what you want it to be, preferably using geographical timezones rather than abbreviation-based ones. If the system clock is then wrong, set it (preferably using NTP, which is all UTC-based and doesn't embed any of these problems, and which will keep the clock in sync going forward).

Improve this answer
0
1

This looks ok to me. Dublin (UTC+0) is currently 6 hours ahead of CST (UTC-6). When you carried out the operation the CST time was 15:47. After the operation the time was 21:48. The time difference is correct.

Improve this answer
2
  • 1
    Yes the difference is correct but I am in Dublin and it is only 09:30AM right now, not 23:30PM which it is now currently saying is GMT time
    – Shane Buckley
    Commented Jan 7, 2017 at 9:33
  • 1
    Then something else is wrong as the timezones are demonstrably working correctly. Why don't you try setting the time to be correct ?
    – user9517
    Commented Jan 7, 2017 at 9:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .