[PATCH] Change abbreviation of Sri Lanka standard time to SLST
According to http://www.sltime.org (maintained by Measurement Units, Standards & Services Department, Sri Lanka) abbreviation for Sri Lanka standard time is SLST. --- asia | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/asia b/asia index 71ef878..dcc8465 100644 --- a/asia +++ b/asia @@ -2768,6 +2768,10 @@ Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 # One possibility is that we wait for a bit for the dust to settle down # and then see what people actually say in practice. +# From Sadika Sumanapala (2016-10-18): +# According to http://www.sltime.org (Official web site of dissemation +# of standard time of Sri Lanka) abbreviation is SLST. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Colombo 5:19:24 - LMT 1880 5:19:32 - MMT 1906 # Moratuwa Mean Time @@ -2777,7 +2781,7 @@ Zone Asia/Colombo 5:19:24 - LMT 1880 5:30 - IST 1996 May 25 0:00 6:30 - LKT 1996 Oct 26 0:30 6:00 - LKT 2006 Apr 15 0:30 - 5:30 - IST + 5:30 - SLST # Syria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -- 2.10.0
Sadika Sumanapala wrote:
Sri Lanka standard time is SLST.
Thanks for bringing this up. The last time I checked, I found few English-language instances of "SLST" standing for time in Sri Lanka. I just now checked again, and although I found more usage, it cannot be said to have taken off. For now, as I mentioned earlier on this mailing list (see the thread ending in <http://mm.icann.org/pipermail/tz/2016-April/023542.html>) I'm inclined to switch to numeric time zone abbreviations like "+0530" for Sri Lanka. We can switch to "SLST" later if it catches on in the broader English-language community. Proposed patch attached.
19.10.2016 12:20, Paul Eggert пишет:
Sadika Sumanapala wrote:
Sri Lanka standard time is SLST.
We can switch to "SLST" later if it catches on in the broader English-language community.
... and if your country is not English-speaking you have to go away with your wishes (like Russia and rest of exUSSR). -- Regards.
On Oct 18, 2016, at 10:41 PM, Pavel V. Rochnyack <rpv@nikolas.ru> wrote:
19.10.2016 12:20, Paul Eggert пишет:
Sadika Sumanapala wrote:
Sri Lanka standard time is SLST.
We can switch to "SLST" later if it catches on in the broader English-language community.
... and if your country is not English-speaking you have to go away with your wishes (like Russia and rest of exUSSR).
If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations or using the Unicode CLDR for translated abbreviations. It's not the job of the tzdb maintainers to provide non-English-language abbreviations; see, for example: $ TZ=Europe/Berlin date Wed Oct 19 09:39:49 CEST 2016 Note that "CEST" ends with "T", not "Z".
19.10.2016 14:41, Guy Harris пишет:
On Oct 18, 2016, at 10:41 PM, Pavel V. Rochnyack <rpv@nikolas.ru> wrote:
19.10.2016 12:20, Paul Eggert пишет:
Sadika Sumanapala wrote:
Sri Lanka standard time is SLST. We can switch to "SLST" later if it catches on in the broader English-language community. ... and if your country is not English-speaking you have to go away with your wishes (like Russia and rest of exUSSR). If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations
Sadika Sumanapala, did you get the answer? If you want abbreviation to be changed, then your software vendor should provide their own time zone database. Did you create support ticket already?
If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations
Whom do you mean by "your software vendor"? If I'm using Debian, then you propose Debian community to build localized tzdb versions for different countries? Later, if some country will change its timezone offset then you also will answer "your software vendor should be providing their own ..." ? Do you realize what your comment offer segregation?
or using the Unicode CLDR for translated abbreviations.
It's not the job of the tzdb maintainers to provide non-English-language abbreviations;
Then tzdb should not provide abbreviations at all. This world has not only English language but tzdb is used world-wide.
-- Regards,
On Oct 19, 2016, at 1:39 AM, Pavel V. Rochnyack <rpv@nikolas.ru> wrote:
19.10.2016 14:41, Guy Harris пишет:
On Oct 18, 2016, at 10:41 PM, Pavel V. Rochnyack <rpv@nikolas.ru> wrote:
19.10.2016 12:20, Paul Eggert пишет:
Sadika Sumanapala wrote:
Sri Lanka standard time is SLST.
We can switch to "SLST" later if it catches on in the broader English-language community.
... and if your country is not English-speaking you have to go away with your wishes (like Russia and rest of exUSSR).
If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations
Sadika Sumanapala, did you get the answer? If you want abbreviation to be changed, then your software vendor should provide their own time zone database. Did you create support ticket already?
If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations
Whom do you mean by "your software vendor"? If I'm using Debian, then you propose Debian community to build localized tzdb versions for different countries?
No, I propose that they (and every other UN*X on the planet) have the code that provides time zone abbreviations use the user's locale to look up the abbreviation in the CLDR, and only use the tzdb's abbreviation if they can't find one in the CLDR.
Later, if some country will change its timezone offset then you also will answer "your software vendor should be providing their own ..." ?
No, I wouldn't. Time zone offsets and DST rules don't require localization; time zone abbreviations do.
or using the Unicode CLDR for translated abbreviations.
It's not the job of the tzdb maintainers to provide non-English-language abbreviations;
Then tzdb should not provide abbreviations at all.
Ideally, no, it shouldn't; as far as I'm concerned, the only reason for providing them in tzdb is that there are UN*X APIs that supply them, so the tzcode sample implementation of the UN*X time zone APIs needs some way of providing them. Actual UN*Xes that provide those APIs should use the CLDR (or, for people who like reinventing the wheel, use their own tables) to get the time zone abbreviation, and only use the tzdb abbreviations if looking up the locale's abbreviation in the CLDR fails. This does, however, raise the question of whether anything other than characters in the "portable character set" are allowed to be provided by UNIX(R) systems (non-UNIX(R) systems, such as the *BSDs and Linux, aren't required to impose such a limitation, but macOS/Solaris/AIX/HP-UX are). The Single UNIX Specification page for tzname: http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzname.html says The tzset() function shall use the value of the environment variable TZ to set time conversion information used by ctime, localtime, mktime, and strftime. If TZ is absent from the environment, implementation-defined default timezone information shall be used. The tzset() function shall set the external variable tzname as follows: tzname[0] = "std"; tzname[1] = "dst"; where std and dst are as described in XBD Environment Variables. and XBD Environment Variables: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_... says TZ This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the ctime(), ctime_r(), localtime(), localtime_r()strftime(), mktime(), functions, and by various utilities, to override the default timezone. The value of TZ has one of the two forms (spaces inserted for clarity): :characters or: std offset dst offset, rule If TZ is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner. The expanded format (for all TZs whose value does not have a <colon> as the first character) is as follows: stdoffset[dst[offset][,start[/time],end[/time]]] Where: std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale. Each of these fields may occur in either of two formats quoted or unquoted: * In the quoted form, the first character shall be the <less-than-sign> ( '<' ) character and the last character shall be the <greater-than-sign> ( '>' ) character. All characters between these quoting characters shall be alphanumeric characters from the portable character set in the current locale, the <plus-sign> ( '+' ) character, or the <hyphen-minus> ( '-' ) character. The std and dst fields in this case shall not include the quoting characters. * In the unquoted form, all characters in these fields shall be alphabetic characters from the portable character set in the current locale. The interpretation of these fields is unspecified if either field is less than three bytes (except for the case when dst is missing), more than {TZNAME_MAX} bytes, or if they contain characters other than those specified. and the Portable Character Set: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html is a subset of ASCII, so no accented Roman-alphabet letters, no non-Roman-alphabet letters, no CJK characters, etc.. However, the "std" and "dst" there refer to the contents of the TZ environment variable when it's a standard POSIX setting. For a POSIX setting, the tzdb abbreviations aren't used, the values from the environment variable are used. So it's not clear what constraints, if any, are placed on the members of tzname[] if TZ is set to :{tzid} or just to {tzid}, e.g. :Europe/Berlin or Europe/Berlin. If the "portable character set" limitation applies only to POSIX settings of TZ, tzname could be set to a string with arbitrary characters, such as "SEČ" (which comes from the CLDR file for Slovak; it's the abbreviation for Central European Standard time, although the Slovak for "standard" isn't part of the abbreviation).
On 10/19/2016 02:40 AM, Guy Harris wrote:
it's not clear what constraints, if any, are placed on the members of tzname[] if TZ is set to :{tzid} or just to {tzid}, e.g. :Europe/Berlin or Europe/Berlin.
POSIX itself places few constraints on tzname if the TZ environment variable is a tzid. However, version 2 and later of the tzfile format mostly defers to POSIX for its newline-enclosed, POSIX-TZ-environment-variable-style strings (used for time stamps far in the future), and this limits us to the POSIX-blessed characters for time zone abbreviations of future time stamps. Although I suppose we could change the tzfile format to extend the character set, that's not something to be done lightly, as I suppose other software relies on things like separating time zone abbreviations with commas, colons, spaces, etc.
On 19/10/16 09:39, Pavel V. Rochnyack wrote:
If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations
Whom do you mean by "your software vendor"? If I'm using Debian, then you propose Debian community to build localized tzdb versions for different countries?
Later, if some country will change its timezone offset then you also will answer "your software vendor should be providing their own ..." ?
tzdb deals in timezones, it doesn't deal in localized timezone names. Localized timezone names come from CLDR (http://cldr.unicode.org/). So, for example, the date in Berlin right now is Wed 19 Oct 11:13:56 CEST 2016 That's English abbreviations and an English timezone name because I'm English. If the timezone name was "MESZ" I would be somewhat confused. If I was German then I'd expect the time to be displayed as Mi 19. Okt 11:13:56 MESZ 2016 The timezone abbreviation isn't actually translated on Linux because glibc (which is responsible for the translation) doesn't localize timezone names. If the localization for the timezones you care about are wrong, then CLDR has a voting mechanism to change them. If you want glibc to use CLDR to localize timezone names then you need to convince the glibc maintainers to make those changes. Bear in mind that the localisation of a timezone name may be different for the person next to you right now. jch
On Oct 19, 2016, at 3:02 AM, John Haxby <john.haxby@oracle.com> wrote:
tzdb deals in timezones, it doesn't deal in localized timezone names. Localized timezone names come from CLDR (http://cldr.unicode.org/). So, for example, the date in Berlin right now is
Wed 19 Oct 11:13:56 CEST 2016
That's English abbreviations and an English timezone name because I'm English. If the timezone name was "MESZ" I would be somewhat confused. If I was German then I'd expect the time to be displayed as
Mi 19. Okt 11:13:56 MESZ 2016
Although, unfortunately: $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.6 BuildVersion: 15G1004 $ LANG=de_DE.UTF-8 TZ=Europe/Berlin date Mi 19 Okt 2016 10:54:31 CEST even though the CLDR appears to have MESZ in common/main/de.xml; as I remember, Apple haven't modified the tzcode-derived *BSD code for handling time zones in the UNIX API, so the "date" command doesn't give you translated abbreviations - some of the Core Foundation or Cocoa frameworks might have APIs that will.
The timezone abbreviation isn't actually translated on Linux because glibc (which is responsible for the translation) doesn't localize timezone names.
As with Linux, so with macOS (*mutatis mutants*, as it doesn't use glibc), at least at the UNIX API level, and probably so with *BSD. I can't speak for Solaris, AIX, or HP-UX.
On 19/10/16 11:15, Guy Harris wrote:
Although, unfortunately:
$ sw_vers ProductName: Mac OS X ProductVersion: 10.11.6 BuildVersion: 15G1004 $ LANG=de_DE.UTF-8 TZ=Europe/Berlin date Mi 19 Okt 2016 10:54:31 CEST
even though the CLDR appears to have MESZ in common/main/de.xml; as I remember, Apple haven't modified the tzcode-derived *BSD code for handling time zones in the UNIX API, so the "date" command doesn't give you translated abbreviations - some of the Core Foundation or Cocoa frameworks might have APIs that will.
Yup. This is probably because no one has felt sufficiently strongly to contribute code to glibc/*BSD or raised enough of a stink with a closed-source vendor :) jch
On Wed, Oct 19, 2016 at 2:09 PM, Pavel V. Rochnyack <rpv@nikolas.ru> wrote:
Sadika Sumanapala, did you get the answer? If you want abbreviation to be changed, then your software vendor should provide their own time zone database. Did you create support ticket already?
Problem is most of the software abbreviation provided by this database directly/default/fallback (eventhough it should be localized). As it is not going to change to SLST, it is better remove IST and replace it with +0530 for now. It is better to have numeric timezone than having wrong abbreivation. As far as I understand this is the current situation: In countries where english is not their native language english timezone abbreviation is mostly used in computer systems. People are not able to use abbreviation when they need because it is not provided by the system. tzdata not going to include the abbreviation because people not using it.
Hi, Dne středa 19. října 2016 9:41:50 CEST, Guy Harris napsal(a):
If your country is not English-speaking, your software vendor should be providing their own translations of time zone abbreviations or using the Unicode CLDR for translated abbreviations.
btw, why should this be done just for non-English-speaking?
It's not the job of the tzdb maintainers to provide non-English-language abbreviations; see, for example:
$ TZ=Europe/Berlin date Wed Oct 19 09:39:49 CEST 2016
Note that "CEST" ends with "T", not "Z".
I'm afraid you're missing the point here (if I got Pavel right, the next answer doesn't shed much light even) - the problem is that tzdb maintainers refuse to provide *English* abbreviations for non-E countries ah, okay, scratch that, there's new reply now:
Then tzdb should not provide abbreviations at all. Ideally, no, it shouldn't; as far as I'm concerned, ...
the problem is, as far as _other_ people are concerned, they find the classical abbreviations useful I did a small survey and I haven't found any supporters of numerical abbreviations among my colleagues - well, that's statistically insignificant of course, but I would consider it a thing to think about, if the only supporters can be found on this list and even on this list, the idea received serious backlash, as we can experience right now I feel sorry for users in Yakutsk[*], for example, who recently got their zone abbreviation changed from YAKT to +09 I believe vitually everyone in Russia able to read Latin could understand what YAKT means now with +09, well, I haven't done local survey, but still I believe the users can be pretty confused whether that means "ninth time zone" or "MSK+09" or what ... there are not many ordinary people familiar with UTC so that the correct "UTC+09" would come into their minds at the first try - the same, as there are not many people following tzdb development/reading full docs to know the correct meaning, they just want to use it, not to study it ... also, from my POV it is very bad that the change was done in a way that it applies even for older timestamps (recently mentioned as a regression in php testsuite), and on old systems that are unlikely to get any noncritical updates, leaving them with unpatched glibc, now suddenly complaining about the "+" sign etc. K. [*] http://www.unicode.org/cldr/charts/30/by_type/timezones.russia.html#Yakutsk -- Karel Volný BaseOS QE - Daemons Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) :: "Never attribute to malice what can :: easily be explained by stupidity."
On 10/19/2016 03:40 AM, Karel Volný wrote:
the problem is, as far as _other_ people are concerned, they find the classical abbreviations useful
Not many people object to truly classical abbreviations like GMT and EST; it's our inventions like LKT that are more problematic.
I believe vitually everyone in Russia able to read Latin could understand what YAKT means
Hmm, well, I just now did a Google search for "YAKT site:ru" and the first match was for a Russian-language description of Yakt, Montana (and I've visited near Yakt and it's beautiful country - but it's not Yakutsk). None of the first ten matches were about Yakutsk time. With more-specialized searches one can find instances of "YAKT" to mean Yakutsk time, largely because of the tzdata invention in earlier releases. But it's more common for English-language sources to call it "Yakutsk time" with no abbreviation; or when abbreviations are used, to say something like "UTC+9" or "MSK+6".
it is very bad that the change was done in a way that it applies even for older timestamps
The tzdata time zone abbreviations are proleptic. That is, they are the English-language abbreviations we use *now* for old time stamps, and these abbreviations may differ from abbreviations used back then (often because hardly anybody used abbreviations back then). It might be nice to also support contemporaneous abbreviations, or abbreviations based on tzdata release number, but that would be a harder task and I will be happy to let some other project take it on if there is interest.
The tzdata time zone abbreviations are proleptic.
As a general rule, yes. There are a few attempts to capture the history of time zone names; in the US take, for example, Eastern War Time and Eastern Peace Time (please). --ado On Wed, Oct 19, 2016 at 4:26 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 10/19/2016 03:40 AM, Karel Volný wrote:
the problem is, as far as _other_ people are concerned, they find the classical abbreviations useful
Not many people object to truly classical abbreviations like GMT and EST; it's our inventions like LKT that are more problematic.
I believe vitually everyone in Russia able to read Latin could understand
what YAKT means
Hmm, well, I just now did a Google search for "YAKT site:ru" and the first match was for a Russian-language description of Yakt, Montana (and I've visited near Yakt and it's beautiful country - but it's not Yakutsk). None of the first ten matches were about Yakutsk time. With more-specialized searches one can find instances of "YAKT" to mean Yakutsk time, largely because of the tzdata invention in earlier releases. But it's more common for English-language sources to call it "Yakutsk time" with no abbreviation; or when abbreviations are used, to say something like "UTC+9" or "MSK+6".
it is very bad that the change was done in a way that it applies even for
older timestamps
The tzdata time zone abbreviations are proleptic. That is, they are the English-language abbreviations we use *now* for old time stamps, and these abbreviations may differ from abbreviations used back then (often because hardly anybody used abbreviations back then). It might be nice to also support contemporaneous abbreviations, or abbreviations based on tzdata release number, but that would be a harder task and I will be happy to let some other project take it on if there is interest.
On Oct 19, 2016, at 1:26 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
With more-specialized searches one can find instances of "YAKT" to mean Yakutsk time, largely because of the tzdata invention in earlier releases.
20.10.2016 3:26, Paul Eggert пишет:
On 10/19/2016 03:40 AM, Karel Volný wrote:
the problem is, as far as _other_ people are concerned, they find the classical abbreviations useful
Not many people object to truly classical abbreviations like GMT and EST; it's our inventions like LKT that are more problematic.
I believe vitually everyone in Russia able to read Latin could understand what YAKT means
Hmm, well, I just now did a Google search for "YAKT site:ru" and the first match was for a Russian-language description of Yakt, Montana (and I've visited near Yakt and it's beautiful country - but it's not Yakutsk).
Did you try to do similar search with other abbreviations? For example, i found (in 'europe'): AMT - it marked as 'invented', none of the first 20 matches time zone abbreviation, but it still in database. When it will be removed? I have just tried: Australia: AWDT, AWST, LINT, MHT, KOST, NRT Asia: SGT, AST, XJT North America: HDT, HST (America/Adak), AKDT, AKST (America/Nome), HST (Zone Pacific/Honolulu) None of 50 first matches for these searches are not about time (skip timezone converter sites, they are based on tzdata). I think, the same can be said about _any_ abbreviation. For HDT even timezoneconverter sites are not in search results. Did you still find google search is reasonable instrument to detect if abbreviation is widely-used?
None of the first ten matches were about Yakutsk time. With more-specialized searches one can find instances of "YAKT" to mean Yakutsk time, largely because of the tzdata invention in earlier releases. But it's more common for English-language sources to call it "Yakutsk time" with no abbreviation; or when abbreviations are used, to say something like "UTC+9" or "MSK+6".
The same can be said about _any_ abbreviation.
it is very bad that the change was done in a way that it applies even for older timestamps
The tzdata time zone abbreviations are proleptic. That is, they are the English-language abbreviations we use *now* for old time stamps, and these abbreviations may differ from abbreviations used back then (often because hardly anybody used abbreviations back then). It might be nice to also support contemporaneous abbreviations, or abbreviations based on tzdata release number, but that would be a harder task and I will be happy to let some other project take it on if there is interest.
Then just remove abbreviations completely.But you somehow think that they are important to some people and unimportant to others. -- Regards,
Pavel V. Rochnyack wrote:
For example, i found (in 'europe'): AMT - it marked as 'invented'
AMT is a more-difficult case, since it is not an integer number of minutes (or even seconds!) from UT so the numeric offset is problematic. We are working on the easier cases first. Most of the other abbreviations you list are on my to-do list, and should be replaced by numeric abbreviations in due course. The North American abbreviations are well-attested enough, which isn't surprising as English is the main language here. If we were designing tzdata from scratch I would indeed favor omitting all abbreviations, as CLDR is a more-appropriate project for them. We don't have that luxury, though.
On Oct 19, 2016, at 3:40 AM, Karel Volný <kvolny@redhat.com> wrote:
I'm afraid you're missing the point here (if I got Pavel right, the next answer doesn't shed much light even) - the problem is that tzdb maintainers refuse to provide *English* abbreviations for non-E countries
ah, okay, scratch that,
Yes, good idea, because (unless Strine isn't considered a form of English :-)) there's at least one E country for which the abbreviations have been disputed - a while ago, there were discussions about what the proper abbreviations were for Australian time zones, and I'm not sure the discussions led to any conclusion. I don't think we should provide abbreviations that aren't commonly used; we definitely shouldn't be *inventing* them.
On Wed, Oct 19, 2016 at 10:50 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
now checked again, and although I found more usage, it cannot be said to have taken off.
Sometimes this happen because in computer applications provide only IST as the abbreviation for Sri Lankan time.
I'm inclined to switch to numeric time zone abbreviations like "+0530" for Sri Lanka. We can switch to "SLST" later if it catches on in the broader English-language community.
+1
participants (7)
-
Arthur David Olson -
Guy Harris -
John Haxby -
Karel Volný -
Paul Eggert -
Pavel V. Rochnyack -
Sadika Sumanapala