Wrong day light saving times in CONFIG_SITE_ENV?

[Dirk Zimoch]

I think the MET TIMEZONE examples are all wrong. In Europe daylight saving time ends 3:00 -> 2:00, not 2:00 -> 1:00 as in the US. Thus all MET TIMEZONE examples should end with 3, not 2. (As far I understand what the hour part means.)
In spring the time is the same in EU and US: 2:00 -> 3:00

See: https://www.timeanddate.com/time/dst/2018b.html

[Andrew Johnson (anj)]

Okay, you probably know that better than I do so I will fix the 3.14 branch and merge up.

I update these entries occasionally to remove old years and add new ones, but it is getting tiresome keeping all our IOCs up to date. Back in 2009 Larry Hoff sent me some code to calculate the VxWorks TIMEZONE value from the Posix TZ variable. This would let us set the rules once and then every time the IOC reboots (and maybe whenever the year rolls over, but at APS we always reboot our IOCs at least once in January anyway) it would calculate the correct TIMEZONE setting for that year. If someone wanted to look at integrating that code into the VxWorks time provider code I'll be happy to forward them a copy.

[Dirk Zimoch (dirk.zimoch)]

I have to admit that I have never actually observed a vxWorks IOC during day light saving time start or end to check at which time it takes place. Not quite my working hours. I just found an inconsistency between the hour in the examples and what I have used here at PSI the last years. Then I looked up the timeanddate website and found the difference in the EU and US switching time in fall. I have never tried to read the underlying code. So I am not sure if the hour means summer time or winter time (or even UTC). If it is summer time the EU times are wrong, if it is winter time the US time seem to be wrong.

It would be much nicer of course to have an algorithm, but not hard coded like in early EPICS versions but with parameters like: +60 minutes from last Sunday in March 2:00 until last Sunday in October 3:00

Or for the US: +60 minutes from Second Sunday in March 2:00 until first Sunday in November 2:00.

Here is the official EU regulation:
http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32000L0084
It mentions 1:00 Greenwich Mean Time, which is 2:00 MET (winter time) or 3:00 MEST (summer time)

[Dirk Zimoch (dirk.zimoch)]

According to my researches all day light saving time changes have always happened on a Sunday everywhere. And they are usually one hour. However there have been "double summer times" in some countries (e.g. mid of May until end of June).

[Andrew Johnson (anj)]

Here's the description of the Posix TZ format from Larry Hoff's source file, which seems to contain a quote from the tzset man-page:

     For simplicity, only the "POSIX standard form" of TZ will be supported.
     Even that is complicated enough (see following spec). Furthermore,
     only the "M" form of DST start and stop dates will be (initially)
     supported.

     TZ=zone[-]offset[dst[offset][,start[/time],end[/time]]]

     zone A three or more letter name for the time zone in normal (winter)
          time.

     [-]offset
          A signed time telling the offset of the time zone westwards from
          Greenwich. The time has the form hh[:mm[:ss]] with a one of two
          digit hour, and optional two digit minutes and seconds.

     dst The name of the time zone when daylight saving is in effect. It may
          be followed by an offset telling how big the clock correction is
          other than the default of 1 hour.

     start/time,end/time
          Specifies the start and end of the daylight saving period. The
          start and end fields indicate on what day the changeover occurs.
          They must be in one of the following formats:

          Jn The Julian day n (1 <= n <= 365) ignoring leap days, i.e. there
               is no February 29.

          n The zero-based Julian day (0 <= n <= 365). Leap days are not
               ignored.

          Mm.n.d
               This indicates month m, the n-th occurrence of day d (1 <= m <=
               12, 1 <= n <= 5, 0 <= d <= 6, 0=Sunday). The 5-th occurrence
               means the last occurrence of that day in a month. So M4.1.0 is
               the first Sunday in April, M9.5.0 is the last Sunday in
               September.

          The time field indicates the time the changeover occurs on the given
          day.

On linux /usr/share/zoneinfo/US/Central is a binary file, but if I run that through strings the last line contains "CST6CDT,M3.2.0,M11.1.0" which is the correct TZ specification for US Central timezone, although it doesn't have the optional /time part.

[Dirk Zimoch (dirk.zimoch)]

/usr/share/zoneinfo/MET contains "MET-1MEST,M3.5.0,M10.5.0/3" so the /time part says 3:00 AM, but only for fall, not for spring. We have 2:00 -> 3:00 in spring and 3:00 -> 2:00 in fall in MET.
Western European time (UK, Portugal) contains "WET0WEST,M3.5.0/1,M10.5.0". They change 1:00->2:00, 2:00->1:00. And Eastern European Time contains "EET-2EEST,M3.5.0/3,M10.5.0/4".
Thus I guess "/2" is the default time. (All over Europe the changeover occurs at the same absolute time across all time zones, thus at different local times.)

NZ-CHAT has "<+1245>-12:45<+1345>,M9.5.0/2:45,M4.1.0/3:45" with time parts which is not at the full hour and a time zone name of "<+1245>"

I have tested our TIMEZONE and confirmed that the hours work in "current time" just like TZ. Thus switching back from 3:00 to 2:00 like in MET requires 03 at the end.

[Ralph Lange (ralph-lange)]

The EPICS IOC on Antarctica is controlled from the Zhongshan station, which is not listed in the overview at https://www.timeanddate.com/time/change/antarctica.
Just saying...

[Dirk Zimoch (dirk.zimoch)]

I guess that the second field in TIMEZONE was supposed to hold the daylight saving time name, but it does not work. The vxWorks 5 manual page for ansiTime calls this field "<unused>".