$gmt(number) works for returning the current timestring, but not when number is a time in the opposite $daylight condition compared to now().

As I understand the time rules, GMT/UTC never goes to daylight time, so the $gmt() datestring for a specific number should always be the same $gmt string regardless of whether daylight time was inside/outside daylight time for either now or the target time:

Code:
//var %a 1547056800 | echo -a asctime: $asctime(%a) vs gmt: $gmt(%a)


With pc time set to USA Central timezone, when the date is during daylight time, this is now showing a 5 hours difference:

asctime: Wed Jan 09 12:00:00 2019 vs gmt: Wed Jan 09 17:00:00 2019

However if I set my pc time to a January date, the $gmt string for the same number changes by 1 hour without shifting the $asctime string:

asctime: Wed Jan 09 12:00:00 2019 vs gmt: Wed Jan 09 18:00:00 2019

Instead of returning the GMT, this appears to returns a time that's simply the $asctime shifted by the current $timezone value, regardless whether the parameter is for a date falling during the opposite daylight daylight condition. $timezone has always changed value depending on whether the current time is during/outside daylight time, where $timezone + $daylight is always the same total, so perhaps the current $timezone value is being applied to all $gmt(number) values throughout the year.

-

This shows the transition date where USA recently went to daylight time:

Code:
//var -s %time $ctime( 2019-03-09 12:00:00) , %i 0 | while (%i isnum 0-24) { var %a $calc(%time + 3600* %i) | echo -a asctime: $asctime(%a) vs gmt: $gmt(%a) | inc %i }


When the clock is set to a January date, the displayed $asctime vs $gmt times begins as 6 hours apart, and for a few hours during the transition they differ by 7 hours, then resumes being 6 hours apart. When the clock is set back to March, the times instead begin as 5 hours apart, then differ by 6 hrs for a few hours, then resume being 5 hours apart. This makes it difficult to get an accurate $gmt(number) string for a distant date without being able to calculate whether $daylight was 0 or 3600 at that point in time.

There should be no 1-hour GMT jump because it never goes on/off GMT.

Another way to describe the issue is that when the target date is in the opposite daylight condition from the current time, shifting by an exact multiple of 86400 seconds should have the $asctime string be shifted by 1 hour, but the $gmt string should not, but it does:

Code:
//var %a $ctime , %b $calc(%a - 59*86400) | echo -a asctime: $asctime(%a) vs $asctime(%b) gmt: $gmt(%a) vs $gmt(%b)


If fixing this breaks backwards compatibility for something, perhaps there can be a new $utc() identifier.