ES6 formatTime for Asia/Kolkata and FunPlanat/moon gives always the same result

[seeh]

 

Could you help me answering this?

ES6 formatTime for Asia/Kolkata and FunPlanat/moon gives always the same result

https://stackoverflow.com/questions/76767940/es6-formattime-for-asia-kolkata-and-funplanat-moon-gives-always-the-same-result

 

[seeh]

On 26/07/2023 at 6:06 AM, seeh said:

 

Could you help me answering this?

ES6 formatTime for Asia/Kolkata and FunPlanat/moon gives always the same result

https://stackoverflow.com/questions/76767940/es6-formattime-for-asia-kolkata-and-funplanat-moon-gives-always-the-same-result

 

the answer at stackoverflow was not helpful. because it works different in web-browsers.

[seeh]

 

@CarltonusIn my time zone the different time zones are displayed correctly. I'm looking for someone to take the test in a different time zone. My time zone is Berlin/Europe.
For that please use the newest Source code of this mod: https://github.com/sl5net/autocivP ZiP: https://api.mod.io/v1/games/5/mods/3105810/files/4098820/download

Start game > Options > Personalization > ... next Full Minute > put a number in e.g. 10
... chose countries: show all
start game and read game name (should be correct)

 

 

Edited July 28, 2023 by seeh

[Carltonus]

const Asia_Kolkata = formatTime(
  new Date(nextHalfHour.getTime() + 3.5 * 60 * 60 * 1000),
  "Asia/Kolkata",

Guess the period/decimal point is the issue here...

[seeh]

10 minutes ago, Carltonus said:

Guess the period/decimal point is the issue here...

there is no issue. it works like expected. (  hopefully also in your continent? not only in Germany )

Edited July 28, 2023 by seeh

[Carltonus]

You see, the Asia/Kolkata entry is unique to the others as it has an entry that isn't an integer, i.e. "3.5". Can you try reproducing with another location in a different time zone? such as "America/Newfoundland" or "Asia/Kathmandu" where these would be rendered also as non-integers too.

[seeh]

5 minutes ago, Carltonus said:

Can you try reproducing with another location in a different time zone?

Why? for which purpose? At the moment it is only important to me that the result is right (also where you life?), not that it is beautiful . But thank you very much. I should sleep now. It's 3 a.m. here.

Edited July 28, 2023 by seeh

[Carltonus]

1 hour ago, seeh said:

where you life?

You meant, "where you live?" Sure, in JavaScript terms, a location close to "America/Los Angeles"; but right now currently on vacation for a few weeks in a location close to "Asia/Manila".

[seeh]

12 hours ago, Carltonus said:

You meant, "where you live?" Sure, in JavaScript terms, a location close to "America/Los Angeles"; but right now currently on vacation for a few weeks in a location close to "Asia/Manila".

Will helpful, if you install it test it, tell me if the times are like expected. will take you maybe 2 minutes i guess.

 

Edited July 28, 2023 by seeh

[s0600204]

spidermonkey, when built as part of the pyrogenesis pre-build process, explicitly and intentionally disables the Intl api due to problems with the spidemonkey build process erroneously inserting an otherwise non-compatible version of the ICU headers into the include search paths of pyrogenesis, causing build failures. (See #5868)

Subsequently, anything that uses the Intl api (e.g. <Date Instance>.toLocaleTimeString()) may not work as expected and (it seems) will fallback on using the local timezone of the computer upon which it is run. As 0 A.D. does not itself make use of this API, this has not been a problem until now.

This is why you've had to use manual timezone offsets - the values of which will most likely only be correct for you and anyone else in your timezone, and only as long as you and your targets don't transition in or out of daylight saving time - instead of being able to leave timezone calculations to .toLocalTimeString(); and also why timezone identifiers are ignored and not validated.

If/when D3127 is merged, it might be possible to re-enable the Intl api - people using a system-repo provided version of spidermonkey will most likely have access to it - but that will need testing and will not happen with the next release.

---

Alternatively, it might be possible to consider building spidermonkey with the --with-system-icu flag instead of the --without-intl-api flag - which also prevents the issue with incorrect ICU headers - although some research may be needed to work out why the latter was used in preference to the former in the first place. (Added as part of the upgrade from SM24 to SM31 in r16214. In SM24 the Intl api was disabled by default; in SM31 it was enabled by default. As we don't use the api, perhaps it was to get a quicker build?)