I can't figure out what's wrong with my TZ string

[scaramanga]

I've been using custom TZ strings for years without a problem. However, what I' trying now isn't working and I can't, for the life of me understand why. Here's my current TZ string:

IST-2IDT,M3.5.5,M10.5.0

I'm in Israel, so we just switched to day light saving, But the NAS time still shows time is 00:22:31 IST (instead of 01:22:31 IDT).

If anyone could take a look and tell me what's wrong I'd be grateful.

[scaramanga]

I forgot to mention that I'm running RC4.1 on a DNS-323 HW Rev c1. I recently upgraded from RC4 and I did the whole script thing that removes the installed updates. I double checked the web UI as well to make sure they were all uninstalled before upgrading.

[João Cardoso]

Don't know. What was your previous working TZ?

On my openSuse-13.2 and also on ftp://ftp.iana.org/tz/code/newtzset.3.txt examples Tel Aviv shows as

IST-2IDT,M3.4.4/26,M10.5.0

Don't know if that will work. Please let me know so I can fix it.

[scaramanga]

The problem with Israel (well, there are plenty of those) regarding the TZ issue is that the day light saving time dates are subject of political debate and change every few years.
That TZ string is the one I've been using for the past few years without a problem and it should work now as well. What it says is change to day light savings time at 2am on the last Friday of March. that date , March 25th is the last Friday of March and it was yesterday. And still, it didn't work, for some reason. That's what baffles me. You can try it yourself and see if you get a different outcome.
That TZ string you gave, IST-2IDT,M3.4.4/26,M10.5.0 - I saw that myself yesterday and tried it (and I'm trying again in order to report what happens accurately). What happens is that after pressing submit the time shown is UTC (= 3 hours behind the actual time. Israel is GMT+2 and the additional 1 hour is because of the day light saving time).
I think it didn't like that /26 bit. It's a little odd to address the following day's 2am as 26hrs.

OK, what I did is mod that TZ string a bit and go for: IST-2IDT,M3.4.5,M10.5.0
which means the 4th Friday of March which is, coincidentally, the last Friday of March. It works.

I'm not sure it's worth perusing this any further, Joao.

[João Cardoso]

On Saturday, 26 March 2016 19:20:17 UTC, scaramanga wrote:

The problem with Israel (well, there are plenty of those) regarding the TZ issue is that the day light saving time dates are subject of political debate and change every few years.
That TZ string is the one I've been using for the past few years without a problem and it should work now as well. What it says is change to day light savings time at 2am on the last Friday of March. that date , March 25th is the last Friday of March and it was yesterday. And still, it didn't work, for some reason. That's what baffles me. You can try it yourself and see if you get a different outcome.
That TZ string you gave, IST-2IDT,M3.4.4/26,M10.5.0 - I saw that myself yesterday and tried it (and I'm trying again in order to report what happens accurately). What happens is that after pressing submit the time shown is UTC (= 3 hours behind the actual time. Israel is GMT+2 and the additional 1 hour is because of the day light saving time).
I think it didn't like that /26 bit. It's a little odd to address the following day's 2am as 26hrs.

Yes, I found that odd too, but it comes from iana.org, The Internet Assigned Numbers Authority (IANA).

But uclibc does not definitively accepts it.

OK, what I did is mod that TZ string a bit and go for: IST-2IDT,M3.4.5,M10.5.0
which means the 4th Friday of March which is, coincidentally, the last Friday of March. It works.

OK, I changed that in my sources (and Jerusalem identically)

You can quickly test several strings from the command line:

date
echo "IST-2IDT,M3.4.5,M10.5.0" > /etc/TZ
date
echo "MINE-2YOUR-3,whatever" > /etc/TZ
date

[scaramanga]

I looked it up, and according to Israeli law's latest amendment from 2013 (careful - PDF; in Hebrew no less), day light saving time starts at 2am on the Friday that precedes the last Sunday of March. Yeah. That can't be expressed using the notation of a TZ string.
The good news is that that 4th Friday of March fits it for the next couple of years. It stops working in 2019. Assuming that the law won't change.

[João Cardoso]

On Saturday, 26 March 2016 20:50:15 UTC, scaramanga wrote:

I looked it up, and according to Israeli law's latest amendment from 2013 (careful - PDF; in Hebrew no less), day light saving time starts at 2am on the Friday that precedes the last Sunday of March. Yeah. That can't be expressed using the notation of a TZ string.
The good news is that that 4th Friday of March fits it for the next couple of years. It stops working in 2019. Assuming that the law won't change.

Others seem to be less fortunate:

From http://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/

As Saudi Arabia gave up trying to cope with their timezone definition, I see no reason to complicate my code further to cope with them. (I understand the intention was to set sunset to 0:00 local time, the start of the Islamic day. In the best case caused the DST offset to change daily and worst case caused the DST offset to change each instant depending on how you interpreted the ruling.)