Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TZ string first offset did not match final defined offset for Africa/Casablanca #123

Closed
philr opened this issue Dec 9, 2020 · 10 comments
Closed

Comments

@philr
Copy link
Member

philr commented Dec 9, 2020

I am receiving the following error when looking up the Timezone info for Africa/Casablanca

irb(main):031:0> tz = TZInfo::Timezone.get('Africa/Casablanca')
TZInfo::InvalidTimezoneIdentifier: The first offset indicated by the POSIX-style TZ string did not match the final defined offset in file '/usr/share/zoneinfo/Africa/Casablanca'.

Originally posted by @dennismonsewicz in #98 (comment)

@philr
Copy link
Member Author

philr commented Dec 9, 2020

@dennismonsewicz What operating system and version are you using? What version of the time zone data package do you have installed? Are you using tzinfo v2.0.3 or v1.2.8? Please could you share the /usr/share/zoneinfo/Africa/Casablanca file?

As a workaround for this you can switch to using the tzinfo-data gem.

@philr philr changed the title TZ string first offset did not match final defined offset for Africa/Casablanca TZ string first offset did not match final defined offset for Africa/Casablanca Dec 9, 2020
@dennismonsewicz
Copy link

dennismonsewicz commented Dec 9, 2020

Thanks for getting back with me @philr!

I am getting these errors in docker using a Mac. Here are the details for the OS in docker

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

I am using v1.2.8 with ActiveSupport (5.2.4.4). That /usr/share/zoneinfo/Africa/Casablanca file looks to be

file /usr/share/zoneinfo/Africa/Casablanca
/usr/share/zoneinfo/Africa/Casablanca: timezone data, version 2, 5 gmt time flags, 5 std time flags, no leap seconds, 100 transition times, 5 abbreviation chars

UPDATE

I have installed the tzinfo-data gem separately and this seems to have fixed the problem. I am testing things further to confirm

@philr
Copy link
Member Author

philr commented Dec 9, 2020

I've downloaded and extracted the files from the latest Debian 9 (stretch) tzdata package (2020d-0+deb9u1) from https://packages.debian.org/stretch/all/tzdata/download. The Africa/Casablanca time zone file loads fine for me (I'm not using Debian, but that shouldn't make a difference).

Please could you confirm which version of the tzdata package you have installed, e.g. by running apt list installed tzdata inside your docker container?

Please could you also upload the /usr/share/zoneinfo/Africa/Casablanca file from the docker container as an attachment so I can examine its contents?

@dennismonsewicz
Copy link

dennismonsewicz commented Dec 9, 2020

root@79b96439f96a:/app# apt list installed tzdata
tzdata/oldstable,oldstable-updates 2019c-0+deb9u1 all [upgradable from: 2018e-0+deb9u1]

Working on getting the file

@philr
Copy link
Member Author

philr commented Dec 9, 2020

I've downloaded the version of the tzdata package you are using (2018e-0+deb9u1) from https://snapshot.debian.org/package/tzdata/2018e-0%2Bdeb9u1. With this version I can now reproduce the error you are seeing.

There's no need to upload your copy of the file.

I'll have a look at what's different with this version and determine whether it's a bug with tzinfo or an issue with the old file.

It is worth noting that version 2018e was released on 2018-05-01 and there have been many changes since (see https://github.com/eggert/tz/blob/master/NEWS). If you rely on time zone data, it'd be a good idea to either keep the Debian tzdata package up to date or use the latest version of the tzinfo-data gem.

@dennismonsewicz
Copy link

dennismonsewicz commented Dec 9, 2020

@philr sounds good. It looks like using the tzinfo-data gem fixes the issues I was seeing. I'll keep an eye on if a fix goes out for the Debian package, though.

@philr
Copy link
Member Author

philr commented Dec 9, 2020

The latest version of the Debian tzdata package is fine. The issue seems to be with older versions only.

philr added a commit that referenced this issue Dec 14, 2020
Required to handle Africa/Casablanca in 2018e.

The last defined transitions are:
  At 2037-03-29 02:00Z change to WEST UTC+1
  At 2037-10-04 02:00Z change to WET  UTC+0

The rules define the end of DST to be at 03:00 local time on the last
Sunday of October (2037-10-31). This later transition needs to be
ignored.

Resolves #123
@philr philr closed this as completed in 0078946 Dec 14, 2020
@dennismonsewicz
Copy link

dennismonsewicz commented Dec 15, 2020

@philr thanks for tackling this! Was there a version bump or just gem install the latest master?

@philr
Copy link
Member Author

philr commented Dec 15, 2020

The fix hasn't been released yet. I'll probably do that soon.

If you want to test beforehand, you can use the 1.2 branch (master won't be compatible with the version of ActiveSupport you are using).

@philr
Copy link
Member Author

philr commented Dec 17, 2020

The fix for this has now been released in versions 1.2.9 and 2.0.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants