Choosing location cites in either India or Nepal does not offer the default local time zones

[John O'Flaherty]

I press the location window [F6] button and open up the location box, and go to the location box to choose a city in the search field. Now that version 0.15.1 supports local time zone for default cities, most will automatically choose the proper local time zone for whatever city one chooses.

(example, if I choose the first city at the top of the list ('Afak, Iraq)... it automatically chooses the "Asia/Baghdad" time zone).

However, if I choose a location-- either in India or Nepal-- it will not give me the proper local time zone, but rather will revert back to "System default" (ones own computer time). Since I live in California, USA... that reverts my time back to UTC-08:00... which of course is no where near India. So it will place the sky objects in the proper place in the sky for that location's time of day, but it will list my time in the bottom panel, instead of India or Nepal's local times, respectively.

I experimented with a few random countries and clicked on their corresponding cities, and was not able to reproduce the problem with any other countries besides India or Nepal. But I may have missed some, as there are a lot of them.

If you need more details, let me know.

-- John

[gzotti (georg-zotti)]

Yes, I have noted some problems here as well. No time yet to investigate, but thanks for the "push".

[Alexander Wolf (alexwolf)]

Can't confirm on Linux.

[gzotti (georg-zotti)]

Apparently, at least on Windows, time zone Asia/Kolkata (used in the site database) is missing in the zone dropdown list. Therefore selecting a site in India does not attach a proper time zone but reverts to "system default" (i.e. user timezone).

[John O'Flaherty (b3burner)]

Dear Mr. Zotti & Mr. Wolf;

Thanks for looking into my bug observation. I had a look at the pull down menu for time-zones and confirmed what you said that a time zone title for "Asia/Kolkata" is not present. However, there is one for "Asia/Calcutta" which (if entered manually); does set the program to the proper UTC+05:30, which the entire country of India is in. I confirmed this via the website 'timeanddate.com'.
I wonder if you had meant to say Calcutta when you said Kolkata? If so Calcutta does exist, but for some reason the program is not pulling it and using it for India locations.

Same goes for Nepal. I confirmed via 'timeanddate.com' that the proper offset for Nepal is UTC+05:45, and there is a time zone title in Stellarium of "Asia/Katmandu", that (if selected manually), will set the clock to the proper UTC+05:45. But upon entering a Nepal location, for some strange reason, it cannot find it on its own.

-- John

[gzotti (georg-zotti)]

Oh yes, different spelling for timezones! Calcutta is Kolkata, and Katmandu is Kathmandu. Is this really not ISO-standardized over our platforms?

[John O'Flaherty (b3burner)]

Hi, I'm not sure what you mean by "ISO-standardized", but yes it would appear that there are some inconsistencies in the spellings of each of the two cities-- between the location search menu, and the time-zone pull-down menu. See the attachment below. Might this be contributing to the issue? Will there be a fix coming for it in the next version?

Also, I don't know if it's appropriate to bring it up in the same bug-query (since it's a similar issue), but I've also noticed some "return to 'system default' " errors in the state of Indiana (United States); though in some instances, it will yield a UTC-6:00 or UTC-5:00 once in awhile. Again, very inconsistent issue, and I'm sure there may be more instances than even the ones I've found.

-- John

[John O'Flaherty (b3burner)]

Just as a point of interest... a partial solution to the issue that I found:

If I take a city in question, change its name ever so slightly to denote the difference (example: "Kolkata (corrected tz)", go to the time zone pull-down menu myself, manually select "UTC+5:30", then hit the "Add to List" button. It will remember the changes I made and yield the proper local time zone, of my new, "slightly altered name", the next time I select it.

The only drawback? You can't "delete from list" any of the *DEFAULT* erroneous place-names with bad time-zones, because that data is apparently hard-coded into the program. Therefore, for each "add to list" city I make for a given city-error, I'll wind up with double the cities in the index; but it is a doable solution (for the time being)-- for the few international cities I wish to use.

Just thought I'd throw that out there, for what it's worth. Finally regarding my add-on comments about the state of Indiana, U.S.-- the "system default" error appears to only happen on the Indiana cities that are in the Eastern time zone (UTC-5:00). The very few that made the list that are in the Central time zone, *DO* display as UTC-6:00 correctly.

Thanks,

-- John

[Alexander Wolf (alexwolf)]

The list of locations and the list of timezone names are not connected between self. We use QTimeZone to manage timezone data. QTimeZone uses a conversion table derived form the Unicode CLDR data to map between IANA IDs and Windows IDs (details: http://doc.qt.io/qt-5/qtimezone.html#details). Depending on your version of Windows and Qt, this table may not be able to provide a valid conversion, in which "UTC" will be returned.

[gzotti (georg-zotti)]

We don't even need the Windows/IANA translations (which are completely different style)! There is a difference in Qt's QTimeZone::availableTimeZoneIds() on Windows and Linux! (Actually I compare Qt5.7 on Win10, Qt5.5.1 on Ubuntu 16.04.1.

No Asia/Kolkata, Asia/Barnaul, Asia/Hebron, Europe/Kirov, Asia/Gaza, Asia/Ho_Chi_Minh, America/Argentina/Cordoba and a few more on Windows, and no Asia/Rangoon on Linux. It seems we must add a few TZ names and cross-translate when necessary 8-O
This will easily require updates as TZ names come and go.

[Alexander Wolf (alexwolf)]

>No Asia/Kolkata, Asia/Barnaul, Asia/Hebron, Europe/Kirov, Asia/Gaza, Asia/Ho_Chi_Minh, America/Argentina/Cordoba and a few more on Windows, and no Asia/Rangoon on Linux.

Just update time zone data on Windows!

[gzotti (georg-zotti)]

This is Win10. I cannot switch *off* regular updates, neither can I find manual TZ updates.
Besides, Asia/Yangon (as it is now called) must be handled as well on Linux...

I am trying a solution...

[Alexander Wolf (alexwolf)]

Please check an optional updates.

[gzotti (georg-zotti)]

I knew about that on Win7. I have yet to find the optional update window on Win10. Maybe this is on Win10pro only?

[gzotti (georg-zotti)]

A first attempt to solve this is in r9204.