I need to get to the time zone array using Chinese,but ,use TimeZone.knownTimeZoneIdentifiers get is English array
TimeZone.knownTimeZoneIdentifiers returns a list of IDs from the IANA TZ Database. A comprehensive list is available here.
These are not to be translated. They are identifiers, passed as parameters to code to identify a time zone. They are always in English, and their exact spelling, casing, and punctuation should remain intact. If you were to translate it, you would find they are not usable in any API.
If your goal is to display a human-readable translated string in a UI, then you should use the localized names provided by the Unicode CLDR project. I am not an iOS developer, so I can't be certain, but from reading the docs, I believe these are already available to you by using the localizedName instance method of the TimeZone class.
Related
Discussing data time-formats, someone mentioned to me how he stores datetime (in a human-readable format) using floats as yyyymmdd.hhmmss, so 2019-09-18, 11:29:30am would become 20190918.112930
I'm trying to find out if this guy has invented his own format or if it is used (and described) elsewhere too - and if so, how is it even called...?
It’s probably homespun
I have seen a lot of date and time formats, and I have not seen this one before. My go is that his guy or his organization invented it themselves.
Edit: Thank you for confirming in the comment. Since comments are not always permanent on Stack Overflow, I quote here, you said:
Finally got confirmation from the source: it's homespun indeed.
As an aside I don’t like it. A float is stored in a binary format internally, and only after formatting it into decimal does it become human readable. Using a float for a “human readable” date and time was not what formatting of floating-point numbers was meant for, it’s a hack.
Use ISO 8601
For a human-readable format I recommend ISO 8601. Here 2019-09-18, 11:29:30am becomes 2019-09-18T11:29:30. Or even better and still within ISO 8601, convert to UTC and append a Z to denote UTC. So if your original time was in Europe/Berlin time zone, it would become 2019-09-18T09:29:30Z. As you can see, ISO 8601 is even more human readable than you friend’s format, and it is sortable as strings (as long as the years don’t go beyond 9999).
While he may have come up with it himself, it is also a formatting option in zipinfo.
The manual doesn't explicitly name it, but describes it as a sortable decimal format and decimal format.
Not sure if we are talking about SQL date format. If so, this date format is present in SQL Statements.
Not sure about the name, it's called in different ways: non-standard, ISO, Other format and so on.
Is present also in PHP.
According to Wikipedia, this would be similar to the ISO 8601, which permits, all of the following for date and time combined:
2019-09-18T09:18:26+00:00
2019-09-18T09:18:26Z
20190918T091826Z
except that the T to separate the time from the date is replaced by . and the time-zone information is dropped.
That specific format has limited popularity either in the yyyymmdd.HHMMSS or the C's strftime()-compatible %Y%m%d.%H%M%S form.
EDIT
As far as using float for date and time the way you suggests, it depends on the precision and machine representation.
If the system is following IEEE 754 basic standard (which is what most modern C compiler stick to), you would need at least float64.
However, it is not common to do so.
This might be in part because it may be difficult to correctly predict the accuracy of the time information, and it is not as bit-efficient as the Unix time.
Given that the only positive feature it has is that it can rely on standard %f from sprintf(), I would only see it advantageous when strftime() is not available or a performance bottleneck.
I am starting this discussion to gather more info on localization practices for APIs. It seems HTTP does NOT provide sufficient guidance and even the state of practice is not sufficient enough.
The basic problem is that APIs may need to provide content that is dependent on the user culture, country, language and timezone. For example a German user would like to read messages in German language, with European metric dates, numbers, units, using Euro currency and in Central European Timezone.
Reading through RFC 7231 Section 5.3.5 Accept-Language and further into RFC 4647 one may think Accept-Language is sophisticated enough and is what should be done. There are several notable shortcomings though:
Language tags may not be precise enough e.g. user may only request language without country code and thus leave ambiguity as: "de, en;q=0.8"
Even if the user supplies both language and country preferences it is not clear how to tie the selection of message locale and value formatting locale. For example if a user requests: "hu_HU, en_US;q=0.9" while the application lacks Hungarian messages and is written in Java that knows how to format date in Hungarian. So should the app use English messages with Hungarian dates or rather provide English messages with US dates? The actual situation may be more complex.
Timezone is not present in the language tags. There is no HTTP standard header for this it seems.
I see Microsoft have thought about #2 in ASP.Net and introduce the notion of Culture and UICulture to separate selection of message language from formatting.
In Java world Spring have introduced TimeZoneAwareLocaleContext to address #3
W3c have issued guideline to Accept-Language used for locale setting. This more or less says that Accept-Language is not enough
So what is your thinking?
Do you know of APIs tat solve this problem in comprehensive way? Pointers?
Should APIs accept multiple values for selecting message language, value formatting locale and timezone?
Should Accept-Language be used at all?
Ok guys,
here is a summary of how I answer my question. I hope this helps future API authors.
The fundamental requirements for an UI based on top of API excluding currency presentation seem to be:
Select the best language out of the available product translations using RFC 4647 list of language ranges
Select the best data format out of the available using RFC 4647 list of language ranges
Allow clients to provide distinct preferences for translation and format. There will be cases where people will not find the best translation and yet prefer to see the proper formatting aligned with their culture.
Allow clients to specify a timezone using IANA TZDB identifiers
Format data elements using Unicode CLDR http://cldr.unicode.org/
Use named placeholders in localization bundles e.g. "{drive} is corrupt" is easier to translate properly than "{1} is corrupt"
On the REST HTTP headers I suggest use of 3 headers
accept-language - used for selecting translation and following the guidelines of RFC 7231 https://www.rfc-editor.org/rfc/rfc7231#section-5.3.5
format-locale - used to select data formatting style if different from the translation language preferences. Again list of language range elements. Defaults to accept-language if omitted.
timezone - used to select timezone for rendering date and time values. This should be valid timezone ID from the IANA TZDB https://www.iana.org/time-zones
Implementation wise it seems Java 8 and later have full capability to implement a globalized application. Other languages and older Java versions seem to have varying degrees of issues.
I would keep all data in a universal locale independent format. For numbers using . as a decimal separator, date and time using ISO 8601 and in UTC, etc.
Provide localized text only if it absolutely necessary. In that case get the locale from accept-language header field, and if you have the localized string pass that. If not fallback to the string you have.
For example, you might a multilingual product database that contains product data in several languages. When you write an API for the database you can select the product data in user's language (if any).
Here is a sample.
In each distribution of LogicBlox, there are two CSV files pertaining to supported time zones:
logicblox-4.x.x
|
└─share
|
└─logicblox
|
└─BlockResources
|
└─timezone
| date_time_zonespec_one_reg_per_tz_code.csv
| date_time_zonespec.csv
Which is the correct one to use when building applications which use time zones? Are valid time zones held in an internal predicate which we can print?
The main timezone specification file is date_time_zonespec.csv. This data is used with datetime-related built-ins, such as datetime:format, parse, create etc. There is currently no way in logic to obtain the list of valid regions or timezone codes.
The file one_reg_per_tz_code is only used to map a timezone code (for example EST) to a default region (for example America/New_York). The reason this file exists is that the lower-level datetime library that we use (boost) supports most timezone notations only as output, not input. The reason for this is that some common timezone notations are surprisingly not a unique indication of a set of timezone rules (e.g. AST/ADT does not have the same rules, and EST is used by Australia as well as the US). Unfortunately, in practice we do have to work with data that uses such timezone notations, so we use this csv file to map the timezone codes to one specific region that does indicate a unique set of timezone rules. This default mapping we picked might not be the desired one for your application though.
It is best to always work with region codes (like America/New_York) to avoid any confusion.
I expect that in the medium-term we will change our datetime and timezone handling to a different library. One reason is the poor parsing support in boost, but another reason is that we really want to use a timezone database with all historical timezone rules, not just the current ones (as specified by this spec file).
I'm working on an app which should create an NSLocale object based NOT on the user's region (which should remain at the user's preferred language for most interface elements), but on the physical location of the traveler, to format currency. However, to build an NSLocale I need to concatenate the language (e.g. 'en') and the location (e.g. 'US') to initWithLocaleIdentifier:#"en_US", and thus to get the currency conventions into the formatter.
I can get the ISOcountry code from the CLPlacemark, but the language information... is harder to identify. Is there a lookup table of language options for each country, or some other option for initializing an NSLocale object based only upon the 'country' information?
I've made a cheap concatenation of #"us_US" which seems to work as well as #"de_DE" (!), but I don't know if I can count on that in all cases.
Thanks,
Tim
For what it's worth, it seems that the NSLocales can in fact be initialized -- at least for the purpose of obtaining currency information -- with 'gb_GB' or 'us_US' locale identifier. I haven't found exceptions in the locations offered by Xcode.
I've been searching for a definitive answer to this, and the XML schema data types document seems to suggest that timezones are accepted, yet I found at least one implementation which does not properly convert time zones ( NUSOAP ).
To make sure that the problem is not at my end, I'd like to know if a format such as 2009-11-05T11:53:22+02:00 is indeed valid and should be parsed with timezone information, i.e. as 2009-11-05T13:53:22.
Given the following sentences from the w3c schema documentation:
"Local" or untimezoned times are
presumed to be the time in the
timezone of some unspecified locality
as prescribed by the appropriate legal
authority;
and
When a timezone is added to a UTC
dateTime, the result is the date and
time "in that timezone".
it does not sound like there is a definitive answer to this. I would assume that it is the usual ambiguity: Both versions are principally valid, and the question of what version to use depends on the configuration/behavior/expectations of the system one is interfacing with.
And even if there where a definitive answer, I would definitely not rely on it, but rather expect that every other web service and library had its own way of dealing with this :/
You converted the timezone incorrectly.
2009-11-05T11:53:22+02:00
is equivalent to
2009-11-05T09:53:22Z
Is that what NUSOAP did?