3

I have an AWS EC2 server running Amazon Linux (like rhel fedora) which does not know how to tell time, or is somehow not accounting for Daylight Savings Time. This makes all of my timestamps off by 1 hour.

[ec2-user@ip-xxx-xx-xx-xxx ~]$ date && date -u
Thu Oct 24 17:19:56 EST 2019
Thu Oct 24 22:19:56 UTC 2019

The problem with that output is that (at the time of the command), the actual time in EST was 18:19:56.

Again, UTC time is correct, I've set my /etc/localtime link to America/Detroit, but it still gloms onto UTC-5 and does not adjust an hour for DST.

[ec2-user@ip-xxx-xx-xx-xxx ~]$ sudo hwclock --debug
hwclock from util-linux 2.23.2
Using /dev interface to clock.
Last drift adjustment done at 1571955488 seconds after 1969
Last calibration done at 1571955488 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2019/10/24 22:23:43
Hw clock time : 2019/10/24 22:23:43 = 1571955823 seconds since 1969
Thu 24 Oct 2019 05:23:43 PM EST  -0.689737 seconds

All of my tzdata is up-to-date. No updates pending on yum.

[ec2-user@ip-xxx-xx-xx-xxx ~]$ echo $TZ

[ec2-user@ip-xxx-xx-xx-xxx ~]$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 23 Dec  8  2015 /etc/localtime -> 
/usr/share/zoneinfo/EST

I'm at a loss. Does anybody know what could be going on? Does Linux not adjust for DST?

Improve this question
10
  • echo $TZ please. Should be empty. And I think you're still on EDT rather than EST. It's strange your server is reporting the wrong label. Commented Oct 24, 2019 at 23:01
  • 1
    @roaima Yes it is empty. Commented Oct 24, 2019 at 23:02
  • TZ=US/Eastern date returns your correct local time, or the one that's wrongly an hour off? Commented Oct 24, 2019 at 23:04
  • 1
    If you change your localtime link to US/Eastern is the problem solved? Commented Oct 24, 2019 at 23:21
  • 1
    I think America/New_York is the standard option. Naively, I had assumed all the "Eastern" zones were equivalent. It hadn't even occurred to me to try swapping them. Commented Oct 24, 2019 at 23:41

1 Answer 1

Reset to default
3

To extend on my comment, in most cases you want to select a city which corresponds to your timezone. It is likely that you do not live in that city. In most cases, it will be one of the largest city of your state, country, or timezone.

For example, in California we use Los_Angeles (full name is America/Los_Angeles).

The plain timezones, such as EST will generally not include definitions for summer and winter times. It is viewed as a generic timezone. UTC is also such a generic timezone. It also happens to be the one computers used as their base time. It does not include any adjustments either (i.e. no leap seconds, no summer/winter changes, a straight forward time, in other words). All the other timezones are now clearly based on UTC.

For the US East Coast, I think you are expected to use America/New_York.

In the US, we have several specialized timezones for places where there is no summer/winter changes. For example, Arizona has never used such clock changes. It remains on the same clock all the time. It has its specific timezone definition: America/Phenix. Alaska Hawaii is another state where they do not change their clock between winter and summer.

Now, I'm pretty sure that in the old days we would just use one of EST, CST, MST, or PST as our computer timezone. That has changed because of all the problems with using such generic designations. If you look at the list of timezones, you'll notice that there are very many of them. And they often get updated as a country or another makes changes to their timezone information.

Improve this answer
1
  • @JimL. Ah! Thanks. I made a correction. Commented Nov 16, 2019 at 5:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.