Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

How do you change the timezone for the HDP cluster?

avatar
New Contributor

We changed the timezone from CDT to GMT on all the nodes in the cluster. Does anyone know what needs to be done in HDP to recognize the new TZ? Do all services need to be restarted?

1 ACCEPTED SOLUTION

avatar
Super Guru

@Bishop Susan

Courageous decision!

I assume you made the change OS-level. You only changed the timezone, not the time and if your jobs are not impacted by the timezone change (you know better), be aware that HDP uses UTC by default. In your case, this is the same you wanted, UTC is GMT with DST awareness and if you are in UK, that does not matter, but you could also change it to GMT, but that will require making some changes service by service and restarting each service. For UI display, you may not have to restart anything. There is no one place do it all. This is an ecosystem of independent tools working together.

Regarding services awareness of timezone, let's take for example Oozie server timezone. Valid values are UTC and GMT(+/-)####. All dates parsed and generated dates by Oozie Coordinator/Bundle will be done in the specified timezone. The default value of 'UTC' should not be changed under normal circumstances. If for any reason is changed, note that GMT(+/-)#### timezones do not observe DST changes. Be aware of that. Usually set the timezone in the Oozie database to GMT. Databases do not handle Daylight Saving Time (DST) shifts correctly, mostly. On a different note, I thought I should raise your awareness that even you changed the timezone in all your nodes, OS-level, your ecosystem also uses some databases like MySQL, PostgreSQL, or Derby for Hive metadata store or Ambari configurations. You may want to check on those too. They should be also GMT like your servers OS.

All other services have a similar configuration. If you want to make a timezone change, this is a tedious effort taking service by service if you want to make the change globally, or setting it in each job pre-requisite settings.

If you were using different timezones because you had MapReduce jobs for which timezone mattered, e.g. processing a calendar day in Japan vs. calendar day in US, then you would need to make a change on how you start each service to include a parameter set to your timezone of choice (tool global) or set it by job session:

SET mapred.child.java.opts= -Duser.timezone=GMT

If you wish to show the new timezone in various UI screens, that is a matter of display configuration and you should do that in the context of HDP configuration via Ambari. For example, if you wish to change the timezone shown in Ambari UI for measured metrics, follow instructions: https://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Users_Guide/content/_setting_disp...

Again, this is a lot for a single response. I just tried to give you a glimpse of the analysis effort needed to plan such a major change avoiding any risk. This is usually tried in development and test environment and all consequences addressed.

If this helped, don't forget to vote/accept answer.

View solution in original post

3 REPLIES 3

avatar
Super Guru

@Bishop Susan

Courageous decision!

I assume you made the change OS-level. You only changed the timezone, not the time and if your jobs are not impacted by the timezone change (you know better), be aware that HDP uses UTC by default. In your case, this is the same you wanted, UTC is GMT with DST awareness and if you are in UK, that does not matter, but you could also change it to GMT, but that will require making some changes service by service and restarting each service. For UI display, you may not have to restart anything. There is no one place do it all. This is an ecosystem of independent tools working together.

Regarding services awareness of timezone, let's take for example Oozie server timezone. Valid values are UTC and GMT(+/-)####. All dates parsed and generated dates by Oozie Coordinator/Bundle will be done in the specified timezone. The default value of 'UTC' should not be changed under normal circumstances. If for any reason is changed, note that GMT(+/-)#### timezones do not observe DST changes. Be aware of that. Usually set the timezone in the Oozie database to GMT. Databases do not handle Daylight Saving Time (DST) shifts correctly, mostly. On a different note, I thought I should raise your awareness that even you changed the timezone in all your nodes, OS-level, your ecosystem also uses some databases like MySQL, PostgreSQL, or Derby for Hive metadata store or Ambari configurations. You may want to check on those too. They should be also GMT like your servers OS.

All other services have a similar configuration. If you want to make a timezone change, this is a tedious effort taking service by service if you want to make the change globally, or setting it in each job pre-requisite settings.

If you were using different timezones because you had MapReduce jobs for which timezone mattered, e.g. processing a calendar day in Japan vs. calendar day in US, then you would need to make a change on how you start each service to include a parameter set to your timezone of choice (tool global) or set it by job session:

SET mapred.child.java.opts= -Duser.timezone=GMT

If you wish to show the new timezone in various UI screens, that is a matter of display configuration and you should do that in the context of HDP configuration via Ambari. For example, if you wish to change the timezone shown in Ambari UI for measured metrics, follow instructions: https://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Users_Guide/content/_setting_disp...

Again, this is a lot for a single response. I just tried to give you a glimpse of the analysis effort needed to plan such a major change avoiding any risk. This is usually tried in development and test environment and all consequences addressed.

If this helped, don't forget to vote/accept answer.

avatar
New Contributor

Constantin, Thank you for all this information. This is exactly what I needed.

avatar
New Contributor

Should have been changed timezones from CDT to UTC.