I can't think of any reason why someone would need $gmt(N) to be applying the current $daylight's offset to times across the entire year. Based on the thread I quote below, I suspect the reasons for changing had to do with the changed on/off times for daylight time, and not from using N against a date 6 months away from the current date.
The only change I've identified that should change would be preventing $gmt(N) from reporting times as if GMT goes on/off daylight time, preventing $gmt(N) from applying the current daylight rules across the entire year. The fix would also allow $gmt(0) to be midnight all year long, instead of reporting during summertime as if it were 11pm Dec 31st.
The parts of the v6.35 behavior I would warn about would be:
#1. applying the effect of the old on/off daylight rules
#2. applying the effect of the old definition of $timezone.
Considering that $gmt(N) is not documented, that seems fair enough.
Actually, $gmt(N) is sorta documented. The documentation is easy to read as if there's support for $gmt(N). Near the top of "/help Time and Date Identifiers" is:
"The identifiers $time(), $date(), and $gmt() can also be used with the format specification below."
This was within the section for $asctime, where it shows 3 kinds of syntax, where 2 of the 3 use the N parameter, so myself and everyone else I've spoken with reads this as applying all 3 kinds of syntax to $gmt and the others.
I tested v7.36 and found the current behavior, so I'm assuming the $gmt behavior changed due to the v7.05 item in
versions.txt:
7.Fixed $gmt and other time-related identifiers to correctly include timezone and daylight offsets.
If so, this thread from a couple months prior to that release is possibly related to this $gmt issue:
https://forums.mirc.com/ubbthreads.php/topics/211013/Re:_$gmt_returning_incorrect_v#Post211013
(#1)
If the changes were made based on that thread, I suspect that the issues they were reporting were caused by the switch in daylight rules. That thread is from 2010 where the new rules had the daylight transition at 2am Sunday March 8th, but v6.35 was hard-coded using the old rules where the transition wasn't scheduled until 2am Sunday April 5th. These posts were in late March of that year, so there were some kinds of 'wrong' results during the 4 weeks between those dates.
In 2019, v6.35 will continue returning the wrong spread between $asctime(N) vs $gmt(N) until this coming Sunday April 7th at 2am. As I mentioned in the prior post, v6.35 within USA timezones will make $asctime($ctime) display the wrong time for the next few weeks, and the workaround for programs using the wrong timezone rules would be to change the clock to use a timezone from 1 hour later which doesn't use daylight rules. i.e. UTC-5 Bogota for USA UTC-6 Central, or UTC-4 Georgetown for USA UTC-5 Eastern.
(#2)
Something else to watch out for is how v6.35 has a different definition of $timezone compared to versions since then. For v6.35, $timezone is a constant number all year long, including the months where $daylight changes from 0 to 3600. However, currently the $timezone value changes so the combined total of $calc($timezone + $daylight) is a constant total, regardless of the $daylight value. For USA Central, $timezone is 21600 during the winter, but changes to be 18000 during summertime. But the combined total of $daylight + $timezone remains 21600 all year long.
Hopefully fixes to $gmt wouldn't cause a whack-a-mole problem with scripts who've become accustomed to the new $timezone definition.
