1

I have two EC2 instances operating in the Oregon location (us-west-2c). Each of these when I issue the command date returns a value 7 hours ahead of what I would expect.

I have tried adjusting the timezone settings and each one returns a date and time much different than I would expect.

Creating the file /etc/sysconfig/clock with a value of ZONE="America/Phoenix" did not provide any change. Even after restarting the instance. (i.e. sudo reboot)

Examples of what I am dealing with and seeing. (All results within 5 minutes of test time stamp.) Time of test : Sat Mar 26 13:24:16 MST 2016 (America/Phoenix)

sudo rm /etc/localtime && sudo ln -s /usr/share/zoneinfo/MST /etc/localtime && date

Sat Mar 26 18:23:35 MST 2016

sudo rm /etc/localtime && sudo ln -s /usr/share/zoneinfo/America/Phoenix /etc/localtime && date

Sat Mar 26 18:24:16 MST 2016

sudo rm /etc/localtime && sudo ln -s /usr/share/zoneinfo/GMT /etc/localtime && date

Sun Mar 27 01:22:21 GMT 2016

So if America/Phoenix is the same as GMT-7 then the above would be calculating correctly. But how is it that America/Phoenix is off by 7 hours?

What time(zone) is Amazon using for Servers in Oregon?

Thanks. Steven

EDIT NOTE: Time of test was noted above incorrectly. This has been updated. - Steven

  • 1
    It doesn't matter what time zone the server itself is in. Set it to whatever you want. – EEAA Mar 26 '16 at 18:37
  • Based upon the commands that I issued, as noted above, setting the time zone does not yield expected results. So what would you recommend I set it to? – Steven K7FAQ Mar 26 '16 at 18:42
  • Your example dates don't show it being 7 hrs off - all show 18 MST, except when you switch to GMT, then it shows 1 GMT, which is correct. Typo? – pete Mar 26 '16 at 20:43
  • 1
    My apologies. The time of the test was 1:24pm Arizona. – Steven K7FAQ Mar 26 '16 at 22:10
  • 2
    FYI, the best practice is that server applications should not rely on the server's time zone setting. Instead, the app should only fetch the time in UTC. If it needs to convert to a different one zone, that should be done in the app itself. Don't rely on the server's time zone to be anything in particular. – Matt Johnson-Pint Mar 27 '16 at 0:32
1

Commonly the system clock is set to UTC and the 'display' timezone is local time. The above configuration looks like it is specifying that the system clock is set to local time instead, which would account for your clock being off by the timezome offset.

Set UTC=true and set the timezone as you already have, you can look at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html for AWS's definition of the process. Relog in and that should resolve the issue.

Additionally, time correctness is not a given on a AWS host so you should consider installing NTPd. Installing ntpd and running ntpdate will also fix your time issue even if you haven't reset the UTC configuration by forcing the time to the correct value.

  • Thank you Jason. I found last night actually that NTPd was not running. You are right on track. – Steven K7FAQ Mar 28 '16 at 16:10
  • FYI: According to the link "The latest versions of Amazon Linux 2 and Amazon Linux AMIs synchronize with the Amazon Time Sync Service by default.", that is if you're using an Amazon Linux AM, ( for instance EKS ) the service chrond is already available and running. – grbonk Jul 19 '19 at 14:17
2

running the command

sudo dpkg-reconfigure tzdata 

and following the on screen wizard helped me.

1

In one of my tutorials I show how to set the timezone on Amazon Linux.

ls -l /usr/share/zoneinfo/        # (Find the applicable zone file)
mv /etc/localtime /etc/localtime.original
ln -s /usr/share/zoneinfo/*ZONEFILENAME* /etc/localtime
# EG I do this below
# ln -s /usr/share/zoneinfo/NZ /etc/localtime

Then edit /etc/sysconfig/clock

ZONE="NZ"
UTC=false
  • Thank you. The creation and setting of timezone in the /etc/sysconfig/clock had no effect. – Steven K7FAQ Mar 26 '16 at 22:18
  • It took me a few goes to work it out, hopefully this works for you too. If it works for you, immediately and after a reboot, please accept this as the answer. – Tim Mar 26 '16 at 22:19
  • 1
    This had no effect – Steven K7FAQ Mar 27 '16 at 0:35
  • Interesting. Sorry but that's all I know, only way for me to do anything else would be to SSH in and look around. Interested to hear if you work it out though. – Tim Mar 27 '16 at 4:11
0

Thank you too all for trying to help me through this problem.

The issue, as I suspected from the beginning, had nothing to do with timezone declarations.

It was found that the NTP daemon was not started and subsequently the ports needed to authorized.

Again, thank you to each for your efforts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.