The Timezone II cookbook contains recipes for installing the latest tzdata (a.k.a. IANA or Olson) timezone database and setting the timezone on your system. It is a fork of the timezone cookbook by James Harton.

This cookbook is known to work with:

• Amazon Linux
• CentOS
• Debian
• Fedora
• Gentoo
• Ubuntu

It should work with any OS that uses the IANA/Olson timezone database and stores local timezone data in /etc/localtime (the only OS I know of that does not do this is MS Windows). However, some OSs not mentioned above have their own system utility for setting the timezone, and this may overwrite the changes made by this cookbook.

Set the "tz" attribute to your desired timezone and include the "timezone-ii" recipe in your node's run list:

{
  "name": "my_node",
  "tz": "Africa/Timbuktu",
  "run_list": [
    "recipe[timezone-ii]"
  ]
}

The default recipe will first install or upgrade the IANA/Olson timezone database package for your OS (timezone-data on Gentoo, tzdata on all others). Then it will call one of the recipes below according to your node's platform.

This changes the timezone on Debian and Debian-derived systems by:

1. writing the value of tz to /etc/timezone, then
2. calling dpkg-reconfigure tzdata.

Only the tz attribute is used; all others are ignored.

This changes the timezone on Fedora by calling timedatectl set-timezone with the value of tz.

Only the tz attribute is used; all others are ignored.

This changes the time on all other OSs. It assumes that the kernel gets data on the local timezone from /etc/localtime. (This is true for FreeBSD as well as Linux, so "linux-generic" is a bit of a misnomer.)

What this recipe does:

1. verifies that the value of tz corresponds with a timezone data file under the directory specified in timezone.tzdata_dir (default: /usr/share/zoneinfo), then
2. creates a copy of or symbolic link to that data file in the path specified in timezone.localtime_path (default: /etc/localtime).

The truthiness of timezone.use_symlink (default: false) determines whether a symlink or a copy is made.

1. Fork the repository on GitHub
2. Create a named feature branch (like add_component_x)
3. Write your change
4. If at all possible, write test-kitchen tests for your change and ensure they all pass
5. Submit a pull request using GitHub

Copyright © 2010 James Harton [email protected]

Copyright © 2013 Lawrence Leonard Gilbert [email protected]

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

 http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.