Made TimeZone string generation locale-agnostic for Windows Phone and Unity. #145
Conversation
There was a problem hiding this comment.
Whoops good catch.
richardjrossiii
force-pushed
the
richardross.timezone.fix
branch
from
bbba380 to
a85b7f4
Compare
… Unity. Previously, TimeZone string generation that we sent along with ParseInstallation was dependent upon the CurrentCulture of the device being set to the english locale (as StandardName is localized, WHAT?!) Our new, fancy TimeZone string is now generated agnostically of the current device locale. There is potential for information about the specific region of the time zone to be lost here, but most applications should not require this. This should fix #138.
richardjrossiii
force-pushed
the
richardross.timezone.fix
branch
from
a85b7f4 to
e076b09
Compare
|
LGTM! |
Made TimeZone string generation locale-agnostic for Windows Phone and Unity.
There was a problem hiding this comment.
Btw, shouldn't this be Etc/GMT{0}{1}..., or simply GMT{0}{1}... will work?
There was a problem hiding this comment.
Let me do a quick REST test and I'll let you know....
There was a problem hiding this comment.
Yep, you're correct, except our backend only supports Etc/GMT+1 (no minutes)... So maybe back to the drawing board. Damn.
|
How can I know in what version this fix goes in? |
|
@meneses-pt Sadly this fix wasn't fully working to begin with, and we're going to be reverting it. We'll keep your issue (#138) updated as we move forward. |
|
It seems like first you should first try and see if there's a match the standard name => iana name dictionary, then you should try this UTC offset thing. Because the UTC offset is not the correct time zone as it doesn't contain daylight savings time info. |
Previously, TimeZone string generation that we sent along with ParseInstallation was dependent upon the
CurrentCultureof the device being set to the english locale (asStandardNameis localized, WHAT?!)Our new, fancy TimeZone string is now generated agnostically of the current device locale. There is potential for information about the specific region of the time zone to be lost here, but most applications
should not require this.
This should fix #138.