PST to PDT changes on April 1st instead of March 11 at 2:00am?

Question

I got the complaint that PST time zone is one hour ahead for Washington in my embedded device. I'm using tz utility to setup the timezone.

This is the Los Angeles time zone :

 2018   Sun, Mar 11 at 2:00 am  PST → PDT   +1 hour (DST start) UTC-7h
        Sun, Nov 4  at 2:00 am  PDT → PST   -1 hour (DST end)   UTC-8h

I even updated the tz utility with the latest 2018 binaries and still get this problem, Am I missing something else?

I'm puzzled after checking the change of PST-PDT on April 1st?

usr/share/zoneinfo # date 031111002018; TZ='America/Los_Angeles' date
Sun Mar 11 11:00:00 UTC 2018
Sun Mar 11 03:00:00 PST 2018
/usr/share/zoneinfo # date 041111002018; TZ='America/Los_Angeles' date
Wed Apr 11 11:00:00 UTC 2018
Wed Apr 11 04:00:00 PDT 2018 <--- Here UTC-7 to UTC-8

---

PST->PDT changes a April 1st 2:00am.

/usr/share/zoneinfo # date 040110242018; TZ='America/Los_Angeles' date 
Sun Apr  1 10:24:00 UTC 2018
Sun Apr  1 03:24:00 PDT 2018

Answer 1

This sounds like your device is using the Pacific-New timezone, which is a proposed timezone that never became law in the US, and which specifies a switch to daylight-savings time on the first Sunday of April:

# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
## Rule Twilite XXXX    max     -       Apr     Sun>=1  2:00    1:00    D
## Rule Twilite XXXX    max     uspres  Oct     lastSun 2:00    1:00    PE
## Rule Twilite XXXX    max     uspres  Nov     Sun>=7  2:00    0       S
## Rule Twilite XXXX    max     nonpres Oct     lastSun 2:00    0       S

Some systems have historically ended up using this instead of the correct Pacific timezone, for a variety of reasons; see this RISKS report (from 1992!) or this Debian bug (from 2016) for examples. There were some issues with this in the first tzdata release of 2018 which may have caused problems on some systems. From the release notes for 2018c:

The default installation procedure no longer creates the backward-compatibility link US/Pacific-New, which causes confusion during user setup (e.g., see Debian bug 815200). Use make BACKWARD="backward pacificnew" to create the link anyway, for now. Eventually we plan to remove the link entirely.

The pacificnew file sets up a link from US/Pacific-New to America/Los_Angeles, and the backward file sets up a link from US/Pacific to America/Los_Angeles. So in theory the data should be correct, however that will depend on what your Los_Angeles file contains.