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?

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.
    – roaima
    Oct 24 '19 at 23:01
  • 1
    @roaima Yes it is empty.
    – Typel
    Oct 24 '19 at 23:02
  • TZ=US/Eastern date returns your correct local time, or the one that's wrongly an hour off?
    – roaima
    Oct 24 '19 at 23:04
  • 1
    If you change your localtime link to US/Eastern is the problem solved?
    – roaima
    Oct 24 '19 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.
    – Typel
    Oct 24 '19 at 23:41
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.

1
  • @JimL. Ah! Thanks. I made a correction. Nov 16 '19 at 5:52

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.