airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
200 stars 11 forks source link

[Windows] `TimeZone` return `rawOffset` and `daylightSavingsOffset` with incorrect sign #3469

Open itlancer opened 3 days ago

itlancer commented 3 days ago

Problem Description

TimeZone return rawOffset and daylightSavingsOffset with incorrect sign for Windows. In reference https://airsdk.dev/reference/actionscript/3.0/TimeZone.html#rawOffset: "The standard offset between this time zone and UTC, in milliseconds."

Tested with multiple AIR 51 versions, even with latest AIR 51.1.1.4 with multiple different Windows devices, different OS versions and different applications. Same issue in all cases. There is no such issue with Android. With Linux another issues like https://github.com/airsdk/Adobe-Runtime-Support/issues/3467 Didn't test with other platforms.

Related issues: https://github.com/airsdk/Adobe-Runtime-Support/issues/3467 https://github.com/airsdk/Adobe-Runtime-Support/issues/3444 https://github.com/airsdk/Adobe-Runtime-Support/issues/3091 https://github.com/airsdk/Adobe-Runtime-Support/issues/3090 https://github.com/airsdk/Adobe-Runtime-Support/issues/2610

Steps to Reproduce

Launch application with code below with any Windows device. It should trace Turkey Standard Time offset (or any you specified).

Application sample with sources attached. windows_timezone_offset_bug.zip

package {
    import flash.display.Sprite;

    public class WindowsTimeZoneOffsetBug extends Sprite {

        public function WindowsTimeZoneOffsetBug() {
            var tz:TimeZone = TimeZone.getTimeZone("Turkey Standard Time");//For Android/Linux use: Turkey
            trace(tz.rawOffset);
            trace(tz.daylightSavingsOffset);
        }
    }
}

Actual Result: In traces you will see:

-10800000
-10800000

Expected Result: In traces you will see:

10800000
10800000

Known Workarounds

1) Multiply result by -1 in your application logic. 2) Use tzutil or other util with NativeProcess to get timezones info. 3) Write own native extension to get timezones info.

ajwfrost commented 3 days ago

That's really odd .. very strange if these have all been wrong from the start, I recall a lot of checks and testing on these (at least on Windows - have seen your notes on Linux, thanks for those!)

Will get these simple updates into our next release..

thanks

ajwfrost commented 3 days ago

Although ... maybe that's actually correct? Based on the JavaScript implementation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset#negative_values_and_positive_values

The number of minutes returned by getTimezoneOffset() is positive if the local time zone is behind UTC, and negative if the local time zone is ahead of UTC. For example, for UTC+10, -600 will be returned.

We'd need to have this consistent on all platforms of course. So .. what would make most sense (and then we probably need to make the documentation clearer on the expected sign of the offset values..)

Looping in @raresn and @Adrian-S as people who had been interested in this feature per #1396

itlancer commented 3 days ago

@ajwfrost Yes, may be JS implementation is correct. As for me - just need consistent behavior on all platforms. For me doesn't matter which sign will be.

raresn commented 3 days ago

Thanks for looping us in! Fortunately for us we do not use the offset in our app.