VMware Cloud Community
jam
Contributor
Contributor

How do I change daylight saving setting?

I have a number of ESX boxes that are currently showing different times due to the daylight saving changes. Some are on GMT and some are on BST(GMT+1). How do I force them onto BST?

All of them are using Europe/London as their timezone, and their UTC time is correct.

Reply
0 Kudos
10 Replies
ChrisDearden
Expert
Expert

are your hosts all talking to the same NTP server ?

If this post has been useful , please consider awarding points. @chrisdearden http://jfvi.co.uk http://vsoup.net
Reply
0 Kudos
jam
Contributor
Contributor

Yes they are. I tried using ntpdate, but that didn't change it to BST.

Reply
0 Kudos
depping
Leadership
Leadership

there's a KB article for this: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1436

Duncan

My virtualisation blog:

If you find this information useful, please award points for "correct" or "helpful".

Reply
0 Kudos
jam
Contributor
Contributor

That kb article is not relevant to my question. The timezones are correct. My problem is the daylight saving. As far as I can tell there is no timezone for BST specifically.

All my machines are on Europe/London timezone, but some are on GMT (winter) and some on BST (summer).

Reply
0 Kudos
jam
Contributor
Contributor

Looking into this further I've found that the /usr/share/zoneinfo/Europe/London file varies between machines.

Doing zdump -v /usr/share/zoneinfo/Europe/London on the incorrect GMT machines gives:

London Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:52 1901 London isdst=0 gmtoff=0

London Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:52 1901 London isdst=0 gmtoff=0

London Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 London isdst=0 gmtoff=0

London Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 London isdst=0 gmtoff=0

Whereas on the correct BST machines it has hundreds of lines detailing the daylight saving changes every year up to 2038.

Any idea how I can recreate this file correctly?

Reply
0 Kudos
jam
Contributor
Contributor

I tried simply copying the London file from a correct server to an incorrect one and that seemed to work.

I'm puzzled as to why this has happened though. The servers were all built in the same way. Does anyone know what controls how the zone files are initially configured?

Reply
0 Kudos
stumpr
Virtuoso
Virtuoso

There were some timezone changes last year, which were implemented as a few vmware esx patches. How are the patch levels on those systems? Consistent? You could locate a correct TZ file for London and copy that to each ESX host. Then update your symlink or replace the /etc/localtime file with the correct London TZ file.

The files should be the same across systems unless something manipulated them (assuming consistent patch levels). You just update /etc/localtime to point at the TZ of your choice.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos
jam
Contributor
Contributor

The patch levels are not entirely consistent, one group of servers have an additional patch that the others do not, but this does not correlate with the timezone problem. Another server with the same patch level had a correct timezone file.

I read about the timezone changes, but they should not have affected the London file.

The only thing that stands out is that the working servers were all rebuilt to Vi3 last winter, and so would have been GMT at the time, whereas the ones with the problem were rebuilt this summer, during BST.

Reply
0 Kudos
stumpr
Virtuoso
Virtuoso

Are some set to use UTC for the hwclock and some not?

Take a look at /etc/sysconfig/clock on your hosts, see if its consistent across your systems.

UTC=true would mean that the hwclock is set to UTC

You can run hwclock --utc but this always shows the time with the local time zone applied, but it should match your proper time if the london timezone file is correct. I wonder if some of your systems may not set to use UTC?

Reuben Stump | http://www.virtuin.com | @ReubenStump
jam
Contributor
Contributor

Ok, checked that. All machines have UTC=true.

Reply
0 Kudos