[bug] Time service response packets have 0 for begin/end DST

[nbriggs]

The Begin/End DST fields of the time service response should not be 0.

BeginDST is the day of the year on or before which Daylight Savings Time takes effect (i.e., the Sunday on
or immediately preceding this day); EndDST is the day on or before which Daylight Savings Time ends.
Days are numbered with 1 being January 1, and counting the days as for a leap year. In the USA
where Daylight Savings Time is observed, BeginDST = 121 and EndDST = 305. In a region where
Daylight Savings Time is not observed at all, BeginDST may be set to 367 (Interlisp uses this,
not sure if other XNS consuming systems used the same 367 convention)

The algorithm and values are set up so that they would not normally need to be changed unless there were a change in the law implementing DST -- "DST begins each year on the second Sunday in March when clocks are set forward by one hour. They are turned back again to standard time on the first Sunday in November as DST ends."

[devhawala]

well, the Pilot based GlobalView 2.1 and ViewPoint 2.0.5 do not really like to get the value 367 for BeginDST:

• booting the first time works well, time is correct (or at least appers to)
• but after shutting down the system normally (saving changes to disk) and the restarting it from scratch result in the boot process stopping with disk problems (MP 0947 for GlobalView 2.1 resp. MP 0948 for VP 2.0.5)

these boot problems disappear after falling back to the disk state before using 367 for BeginDST and using 0 again.

very strange... (i did the above experiment loop twice as i did'nt believe that a BeginDST 367 causes the problem)

Is a BeginDST = 0 really a problem for Medley? does it really get the internal time from an XNS time server if connected to a network (as Pilot OSes at MP 0937)? i would have expected that Medley uses the time from the host OS it runs on.

[nbriggs]

Medley has a choice -- either picking up the time (but not the begin/end DST and time zone offset) from the host OS, or, if it finds an XNS time service, it can pick up everything from there. Are the Begin/End DST and time zone offset configurable in a time service configuration file? If so, that's fair enough.

[devhawala]

Currently only the time zone offset is configurable (parameter localTimeOffsetMinutes), leaving it to the user to adapt the offset in the Dodo configuration file when DST starts or stops.

But i can also make the begin/end DST values configurable: if both values are given and valid (1..366), these will be used by the time service instead of 0 in the time response packets.

(i'm thinking of using the syntax offsetMinutes[:dstFirstDay:dstLastDay] of the --tz commandline parameter of my ST80 Smalltalk emulator, so those code snippets can be reused; just an idea)

[nbriggs]

Sure, I'm not wedded to any particular syntax for the configuration.

[devhawala]

the new version of Dodo just uploaded has 2 new configuration parameters timeService.dstFirstDay and timeService.dstLastDay for optionally specifying the DST begin and end, see the documentation in the readme.