Yes, v6.35 returns the expected $gmt times. The 1st example showed the GMT time-string ending with 18:00:00 regardless whether the pc clock is Jan 19 or Apr 19. Neither of these calendar dates shows the GMT jumping by an extra hour on the transition date to/from daylight mode, though the rules were different back then, so the command needed to edit the date to either 2018-10-27 12:00:00 or 2019-04-06 12:00:00 instead, which both make that snippet show the $asctime(N) changing by 2 or 0 hours at 2am but the $gmt(N) doesn't.
And this revised snippet shows any dates within +/- 183 days of today, by adding or subtracting a multiple of 86400 seconds. It displays any date where the GMT time-of-day differs from the current time. For both Jan19/Apr19, in v6.35 it correctly shows no dates, but in 7.55 it shows every date in the opposite daylight-state compared to the date the pc clock is set to.
//var %a $ctime , %i -183 , %gmtnow $gettok($gmt(%a),4,32) | while (%i < 183) { var %gmt $gmt($calc(%a + 86400*%i)) | if ($gettok(%gmt,4,32) != %gmtnow) echo -a %i : %gmt vs %gmtnow | inc %i }
I tested Apr19 in case there was a side-effect from v6.35 seeing the daylight rules differently than they really are. When setting the pc clock to a date between the new/old transition dates, including today, v6.35 reports $asctime($ctime) as being 1 hour ago.
