Time Zone acronyms review on Windows

[Vincent]

It seems that on non-English versions of Windows, time zone acronyms that are displayed within the time/date overlay can sometimes be confusing. As an example, my French version of Windows returns "Paris Madrid" as the timezone name instead of "Western European Time". Celestia then displays "PM" as the time zone acronym instead of the standardized "WET" abbreviation, which can be quite confusing:



It would be interesting that a maximum of users on non-English Windows version report how time zone is displayed on their system. Just switch to local time, and please report your time zone acronym, along with your version of Windows such as:

---------------------------------
Windows version: French
Time Zone Acronym: PM
---------------------------------

Thanks !

[Fenerit]

Windows version: Italian
Time Zone Acronym: osEo

[Adirondack]

---------------------------------
Windows version: German
Time Zone Acronym: WN
---------------------------------

WN = Western European Normaltime

Latest CVS


Adirondack

[Vincent]

Massimo, Ulrich, Thanks.

Has anyone else noticed this kind of weird time zone abbreviations ?

[Christophe]

Vincent, I was thinking wouldn't it be even simpler not to display the timezone at all when using local time?

Specify UTC when it is in use and simply nothing otherwise, or maybe just 'DST' or 'STD' which is readily available in struct tm.

I don't see any way to solve this problem short of integrating zoneinfo. Note also that the switch to Qt probably won't solve the problem since Qt relies on the system's API for timezones.

[Vincent]

Vincent, I was thinking wouldn't it be even simpler not to display the timezone at all when using local time?

Christophe,

I would certainly agree with that, since time zone acronyms can sometimes be quite confusing, and when they're not, they don't bring that much information.

Then, would users who have a correct time zone acronym displayed on their system also agree with that ?

[BobHegwood]

Vincent, I was thinking wouldn't it be even simpler not to display the timezone at all when using local time?

Specify UTC when it is in use and simply nothing otherwise, or maybe just 'DST' or 'STD' which is readily available in struct tm.

For what it's worth, I like the 'STD' option. Sounds like a reasonable
alternative to the spaghetti mess you guys are seeing now. Since I'm
one of the spoiled EST people here, this wouldn't bother me for our
use either. If the user see's 'STD' he or she KNOWS what time zone
they're set up for, yes?

Thanks, Brain-Dead

[ajtribick]

Hmmm... not so sure that STD is such a good choice.

(Sorry to lower the tone)

[BobHegwood]

Hmmm... not so sure that STD is such a good choice.

(Sorry to lower the tone)

Have you an alternative? I'm sure that the developer types here can
accommodate most anything with which you might be happier.

[Christophe]

We could use STD/DST and mark the strings for translation. That way the translator can use what is best depending on the language. For exemple: heure d'hiver/heure d'?©t?© in French.

[Vincent]

For exemple: heure d'hiver/heure d'?©t?© in French.

Hmm, wouldn't that be a little bit too long ?

[Christophe]

Well, there is no hard limit on the size of the timezone name. Since in French there is no common abbreviation I guess it's either that or nothing.

My patch if finally ready, you can get it here.

There are three formats available:
- Locale: uses strftime %c under Linux, same as TZName under Windows
- TZName: 'YYYY MMM DD HH:MM:SS TZName' with TZName the timezone name under Linux and the localized versions of DST/STD under Windows
- UTCOffset: 'YYYY MMM DD HH:MM:SS ?±HHMM'

Of course this can easily be extended to include new formats.

For the time being you can cycle through the formats with 'D' (Demo is disabled).

Here are some examples under Linux:

[Vincent]

Christophe,

I've not tested your patch yet, since I'm quite busy at the moment.
I'll probably have a chance to test it next week end.
The examples you've posted looks promising, though.
Are you planning to add the 3 formats option in celestia.cfg ?

[Christophe]

Are you planning to add the 3 formats option in celestia.cfg ?

Following the discussion on the mailing list, I was rather planning on adding hooks to CelestiaCore and let the GUIs handle it as a new configuration option.