Re: [tz] EST/EDT vs AEST/AEDT in AQ [SEC=UNCLASSIFIED]
From: tobias.conradi@gmail.com [mailto:tobias.conradi@gmail.com] On Behalf Of Tobias Conradi
This is a vote to use AEST/AEDT, or switch completely to Internationalized time point unique abbreviations.
I have been very clear since my very first email that may main concern is with the daylight savings abbreviations.
Again switching completely to Internationalized time point unique abbreviations is outside the scope of the tz database. Again? Where did you say it is outside the scope of the tz database before?
Where is the scope defined to have EDT? Going for "out of scope" without citing policy looks like trying to conceal that fact that it is only outside your scope.
For the scope of changes that can be made to the tz database please read: http://www.iana.org/go/rfc6557 No one is trying to conceal anything I'm simply following the procedures outlined in that document.
You seem to not care about anything outside Australia and deteriorating the database by introducing new meanings of D is not problem for you.
I can accuse you of trying to introduce a new meaning to Australians. Please show me where it says that we must use the abbreviations used elsewhere in the database. Your own table shows that the abbreviations letters can mean different things. AGAIN you are trying to enforce unique and standardised abbreviations, as I have said this would be great if the world as a whole decided to use such standards but there is no such thing currently, if I'm wrong please enlighten me. Again: "Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry."
We are simply trying to get the daylight savings abbreviations changed to what is *actually* used in Australia. Macquarie Island in the IANA time zone database is AQ and not Australia.
Macquarie island is part of Australia: http://en.wikipedia.org/wiki/Macquarie_Island Timothy Arceri
Tim, FTR: You now put a private reply to a private email of yours to me on the list. On Fri, Apr 12, 2013 at 5:35 AM, Timothy Arceri <T.Arceri@bom.gov.au> wrote:
From: tobias.conradi@gmail.com [mailto:tobias.conradi@gmail.com] On Behalf Of Tobias Conradi
This is a vote to use AEST/AEDT, or switch completely to Internationalized time point unique abbreviations.
I have been very clear since my very first email that may main concern is with the daylight savings abbreviations.
Again switching completely to Internationalized time point unique abbreviations is outside the scope of the tz database. Again? Where did you say it is outside the scope of the tz database before?
Where is the scope defined to have EDT? Going for "out of scope" without citing policy looks like trying to conceal that fact that it is only outside your scope.
For the scope of changes that can be made to the tz database please read: http://www.iana.org/go/rfc6557
Scope of changes and scope of the database are two things, right?
No one is trying to conceal anything I'm simply following the procedures outlined in that document.
You seem to not care about anything outside Australia and deteriorating the database by introducing new meanings of D is not problem for you.
I can accuse you of trying to introduce a new meaning to Australians. Of course.
Please show me where it says that we must use the abbreviations used elsewhere in the database. That I cannot.
Your own table shows that the abbreviations letters can mean different things. D for %s never means anything else than 1:00 saving. HD and HS for %s always mean less than 1:00 saving and DD and DS always mean 2:00 saving.
So, you introduce a new meaning for D for %s.
AGAIN you are trying to enforce unique and standardised abbreviations, using D, DD, DS, HD, HS as has been done in the database for %s does NOT make the abbreviations unique.
AGAIN: You are confusing topics.
as I have said this would be great if the world as a whole decided to use such standards but there is no such thing currently,
There is a standard for %s
if I'm wrong please enlighten me. I can only present facts to show that you are wrong. Whether you are able to use these for enlightenment is outside my range of influence.
Again: "Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry."
We are simply trying to get the daylight savings abbreviations changed to what is *actually* used in Australia. Macquarie Island in the IANA time zone database is AQ and not Australia.
Macquarie island is part of Australia: http://en.wikipedia.org/wiki/Macquarie_Island
In Wikipedia, not in the IANA time zone database. ftp://ftp.iana.org/tz/data/zone.tab AQ -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Fri, Apr 12, 2013, at 4:45, Tobias Conradi wrote:
Your own table shows that the abbreviations letters can mean different things. D for %s never means anything else than 1:00 saving. HD and HS for %s always mean less than 1:00 saving and DD and DS always mean 2:00 saving.
So, you introduce a new meaning for D for %s.
There is no rule that a specific string always means a specific time offset. The rule is supposed to be to use what is used locally. For example, New Zealand before 1945 uses NZMT/NZST for 0:30 saving. European rules use "M" for "midsummer" 2:00 saving time of the 1940s even though other rules use it for "mean" time. You are inferring a systematism where non exists.
On Fri, Apr 12, 2013 at 2:38 PM, <random832@fastmail.us> wrote:
On Fri, Apr 12, 2013, at 4:45, Tobias Conradi wrote:
Your own table shows that the abbreviations letters can mean different things. D for %s never means anything else than 1:00 saving. HD and HS for %s always mean less than 1:00 saving and DD and DS always mean 2:00 saving.
So, you introduce a new meaning for D for %s.
There is no rule that a specific string always means a specific time offset. You mean y written one? I can write one. And even without a written one, the implementation shows that D in %s is never 1:00 saving.
The rule is supposed to be to use what is used locally. Which rule? Why then is WIT meaning Western Indonesian Time? Why is there SET for Sweden?
For example, New Zealand before 1945 uses NZMT/NZST for 0:30 saving. Again, no D for non-1:00 saving.
European rules use "M" for "midsummer" 2:00 saving time of the 1940s even though other rules use it for "mean" time. As documented http://anna.info/wiki/IANA_time_zone_database#Abbreviations
You are inferring a systematism where non exists. The facts have been presented. If you don't see the system behind the facts - never use D in %s to mean non-1:00 saving, then I cannot help you.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Fri, Apr 12, 2013, at 10:42, Tobias Conradi wrote:
The facts have been presented. If you don't see the system behind the facts - never use D in %s to mean non-1:00 saving, then I cannot help you.
There is no "system", only _coincidence_ You don't seem to recognize that a coincidence can happen and not mean that future usage should be constrained to match what coincidentally happened in the past. No-one is relying on "D" always to mean exactly 1:00 any more than they are relying on "S" to mean standard or daylight savings itself [i.e. isdst=1] to mean 1:00. (The latter is actually the only thing likely to be happening at all, despite being demonstrably incorrect)
When I was a data administrator, one of the most fundamental principles I learned was not to try to embed one field as a code inside another one. For example, most Austrian postal codes allow you to infer the state from the first digit. The postal code 5016 is in Salzburg; Koppl is 5321; Tenneck is 5451; they're all in Land Salzburg. So why not use the postal code field to figure out which state a place is in? Because sooner or later, someone will change the system. (In fact, there are already a few exceptions in the case of Austria.) I believe that the same principle applies to tz abbreviations. If programmers get the idea that they can rely on the next-to-last letter of the tz abbreviation to represent the offset from standard time, with H = .5 and D = 1, at least a few of them will start writing code that makes that assumption. (Some programmers love to think up tricks like that, in order to save a line or two of code.) It's just not a good data design. The tz database contains a field that's defined as the offset from standard time, and it's expressed as a time, not a letter code. Force the programmers to use that field. Never suggest that the next-to-last letter can be used instead. Gwillim Law
Gwillim Law said:
When I was a data administrator, one of the most fundamental principles I learned was not to try to embed one field as a code inside another one. [...] (Some programmers love to think up tricks like that, in order to save a line or two of code.) It's just not a good data design. The tz database contains a field that's defined as the offset from standard time, and it's expressed as a time, not a letter code. Force the programmers to use that field. Never suggest that the next-to-last letter can be used instead.
Hear, hear. These abbreviations are there for hysterical raisins (as we used to call it in my youth). They're already fundamentally broken - trying to add structure to them is doomed. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Hang on here. Choosing to not use 'D' to mean something different from everything else is not "overloading" the field. If I understand correctly, the region in question, Lord Howe, has three seasonal variations. If there is a Standard and a Daylight and a Half, I think it makes sense for them to use different abbreviations. As we noted earlier, one of the frequent use cases of the abbrevs is for a user to type 'date' and use the abbrev output to determine which seasonal variation we are in (in my case, whether I am in US/Eastern's Eastern Daylight Time or Eastern Standard Time). On the other hand, I don't think LHDT/LHST/LHHDT is a good choice, because like it or not, some people get confused by the 'D'. Be liberal in what you accept, but rigorous in what you send. I think LHDT/LHST/LHHT was originaly proposed? To me that would be better. What is the downside to it? Maybe that's what we're discussing? I can't tell, the discussion has gotten so abstract without concrete examples and looking back at the last 50 or so tz messages that mention Lord Howe is not supre-clear. --jhawk@mit.edu John Hawkinson Clive D.W. Feather <clive@davros.org> wrote on Mon, 15 Apr 2013 at 13:50:54 +0100 in <20130415125054.GF35846@davros.org>:
These abbreviations are there for hysterical raisins (as we used to call it in my youth). They're already fundamentally broken - trying to add structure to them is doomed.
John Hawkinson said:
If I understand correctly, the region in question, Lord Howe, has three seasonal variations.
As I understand it, it has two: winter and summer. What's unusual is that they're 30 minutes apart (winter is UTC+10:30, summer is UTC+11:00).
On the other hand, I don't think LHDT/LHST/LHHDT is a good choice, because like it or not, some people get confused by the 'D'. Be liberal in what you accept, but rigorous in what you send.
What we actually want to know is what Lord Howians actually use.
I think LHDT/LHST/LHHT was originaly proposed? To me that would be better. What is the downside to it?
It's unrelated to what anyone there uses? (There's only 347 of them. Perhaps someone could go out and do a poll.) But my point, reiterating Gwillim, is that you don't want to have "standard" letters for offsets - particularly ones that aren't used by the locals - because that will encourage bad programming practice. The abbreviation section of the database seems to have caused more argument and more cranks coming out of the woodwork than the rest put together. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive@davros.org> wrote:
On the other hand, I don't think LHDT/LHST/LHHDT is a good choice, because like it or not, some people get confused by the 'D'. Be liberal in what you accept, but rigorous in what you send.
What we actually want to know is what Lord Howians actually use. Why? Me not. Localization is out of scope of the database. This belongs to CLDR.
E.g. for Europe there is CET/CEST for all countries in the database, but no one cares what the locals do https://www.google.com/search?q=Uhr+CET+site%3Afaz.net https://www.google.com/search?q=Uhr+MEZ+site%3Afaz.net
I think LHDT/LHST/LHHT was originaly proposed? To me that would be better. What is the downside to it?
It's unrelated to what anyone there uses? It is not.
But my point, reiterating Gwillim, is that you don't want to have "standard" letters for offsets To the contrary, it seems John wants exactly that, like me.
- particularly ones that aren't used by the locals - what locals do does not matter
because that will encourage bad programming practice. It will improve the usability of the database.
The abbreviation section of the database seems to have caused more argument and more cranks coming out of the woodwork than the rest put together. And the day you have somplaceDT and someplaceHDT in the same country next to each other, exactly your approach will lead to more debate.
But TZ database maintainers cannot /stop/ debate by choosing one abbreviation or the other. What they can stop is ambiguity. And using the letter D in a new meaning paves the road for ambiguity. Reserving D in %s for 1:00 offset as has been done over years, i.e. is established practice, is the way to prevent certain kinds of possible ambiguities. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 04/15/13 07:59, Tobias Conradi wrote:
Reserving D in %s for 1:00 offset as has been done over years, i.e. is established practice
I'm not quite following all the proposal in this area, but "D" also stands for "Double", as in BDST for British Double Summer Time. There is a similar usage of "H" for Half, as in CKHST for Cook Islands Half Summer Time. If memory serves, CKHST, UYHST, etc. are my own invention, while BDST is not: it comes from contemporaneous British sources. I came up with HST by analogy from DST.
On Mon, Apr 15, 2013 at 6:57 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 04/15/13 07:59, Tobias Conradi wrote:
Reserving D in %s for 1:00 offset as has been done over years, i.e. is established practice
I'm not quite following all the proposal in this area, but "D" also stands for "Double", as in BDST for British Double Summer Time. There is a similar usage of "H" for Half, as in CKHST for Cook Islands Half Summer Time. If memory serves, CKHST, UYHST, etc. are my own invention, while BDST is not: it comes from contemporaneous British sources. I came up with HST by analogy from DST.
My statement was a shortening, that shortening made it wrong. I meant in the position immediately before the last T. For saving time there is immediately before the last T D 1:00 S 1:00 DD 2:00 DS 2:00 HD 0:30 HS 0:30 and 0:20 Conforming with this established practice is LHHDT for Lord Howe Half Daylight saving Time. In the beginning of the 1980 saving was 1:00, so I proposed LHDT there. In 1985 there was both. Until March 1:00 saving, suggesting LHDT. From October 0:30 saving, suggesting LHHDT. If in October the abbreviation is the same, then it might be confusing. It could be that the data source for a clock was not updated, and it uses 1:00 by error. If one clearly distinguishes between half and full hour saving in the abbreviation, then everyone who sees a clock time and the abbreviation, is at least pointed to the fact that something is not as in the saving periods before. An area can also split during saving time, and xDT and xHDT exist side by side. If one would label both as xDT, there could be the same tsunami warning ambiguities as mentioned by the Australian BOM people to this mailing list. Summary for Lord Howe: LHST Lord Howe Standard Time - save 0:00 LHDT Lord Howe Daylight saving Time - save 1:00 LHHDT Lord Howe Half Daylight saving Time - save 0:30 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Tobias Conradi <mail.2012@tobiasconradi.com> wrote on Tue, 16 Apr 2013 at 02:53:16 +0200 in <CAAGevbVts2-_svZLVohwN7E+U-aTkMAdQCpgG_h5s78E=HQBDQ@mail.gmail.com>:
Summary for Lord Howe:
LHST Lord Howe Standard Time - save 0:00 LHDT Lord Howe Daylight saving Time - save 1:00 LHHDT Lord Howe Half Daylight saving Time - save 0:30
Why would we prefer LHHDT to "LHHT"? --jhawk@mit.edu John Hawkinson
On Tue, Apr 16, 2013 at 2:57 AM, John Hawkinson <jhawk@mit.edu> wrote:
Tobias Conradi <mail.2012@tobiasconradi.com> wrote on Tue, 16 Apr 2013 at 02:53:16 +0200 in <CAAGevbVts2-_svZLVohwN7E+U-aTkMAdQCpgG_h5s78E=HQBDQ@mail.gmail.com>:
Summary for Lord Howe:
LHST Lord Howe Standard Time - save 0:00 LHDT Lord Howe Daylight saving Time - save 1:00 LHHDT Lord Howe Half Daylight saving Time - save 0:30
Why would we prefer LHHDT to "LHHT"?
Because xHDT and xHST are established practice in the database. For the double saving counterpart xDDT and xDST are used. If one wants to change that, then maybe for all xHDT and xHST. Answering in one word: consistency. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Tue, 16 Apr 2013, Tobias Conradi wrote:
On Mon, Apr 15, 2013 at 6:57 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 04/15/13 07:59, Tobias Conradi wrote:
Reserving D in %s for 1:00 offset as has been done over years, i.e. is established practice
I'm not quite following all the proposal in this area, but "D" also stands for "Double", as in BDST for British Double Summer Time. There is a similar usage of "H" for Half, as in CKHST for Cook Islands Half Summer Time. If memory serves, CKHST, UYHST, etc. are my own invention, while BDST is not: it comes from contemporaneous British sources. I came up with HST by analogy from DST.
My statement was a shortening, that shortening made it wrong.
I meant in the position immediately before the last T.
For saving time there is immediately before the last T D 1:00 S 1:00 DD 2:00 DS 2:00 HD 0:30 HS 0:30 and 0:20
Conforming with this established practice is LHHDT for Lord Howe Half Daylight saving Time.
Why are you encoding meaning in abbreviations? Abbreviations are a disply-only feature. Also, there is no such thing as "Half Daylight Saving Time". It's an on/off switch, no matter whether they change by 30 minutes or 427 seconds. cheers, Derick
On Tue, Apr 16, 2013 at 12:10 PM, Derick Rethans <tz@derickrethans.nl> wrote:
Why are you encoding meaning in abbreviations? If you don't care about meaning, why do you discuss?
Abbreviations are a disply-only feature. With meaning.
Also, there is no such thing as "Half Daylight Saving Time". It's an on/off switch, no matter whether they change by 30 minutes or 427 seconds. Tell the Brits:
https://www.google.com/search?q=%22British+Double+Summer+Time%22+site%3Auk -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 15 Apr 2013, at 17:57, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 04/15/13 07:59, Tobias Conradi wrote:
Reserving D in %s for 1:00 offset as has been done over years, i.e. is established practice
I'm not quite following all the proposal in this area, but "D" also stands for "Double", as in BDST for British Double Summer Time. There is a similar usage of "H" for Half, as in CKHST for Cook Islands Half Summer Time. If memory serves, CKHST, UYHST, etc. are my own invention, while BDST is not: it comes from contemporaneous British sources. I came up with HST by analogy from DST.
Speaking of Britain, it would be interesting to know how "D" and "S" would apply to GMT and BST. You'd use BST for winter time and BDT for summer time perhaps? It's a pity that BST is the daylight savings time and Britain is emotionally attached to GMT :) jch
On Apr 15, 2013, at 7:59 AM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive@davros.org> wrote:
On the other hand, I don't think LHDT/LHST/LHHDT is a good choice, because like it or not, some people get confused by the 'D'. Be liberal in what you accept, but rigorous in what you send.
What we actually want to know is what Lord Howians actually use. Why? Me not. Localization is out of scope of the database. This belongs to CLDR.
Another way to think about this is to say The abbreviations supplied by the tz database are the abbreviations appropriate for the C locale. For any other locale, go to CLDR. And, yes, this argues that implementations of the tzname[] array, and of strftime(), in UN*X systems should contain more code than just what you get with tzcode, so that it goes to the CLDR for time zone abbreviations for locales other than the C locale.
On Tue, Apr 16, 2013 at 2:58 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Apr 15, 2013, at 7:59 AM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive@davros.org> wrote:
What we actually want to know is what Lord Howians actually use. Why? Me not. Localization is out of scope of the database. This belongs to CLDR.
Another way to think about this is to say
The abbreviations supplied by the tz database are the abbreviations appropriate for the C locale.
I guess "C locale" is not restricted Lord Howe English. LHDT and LHHDT are both abbreviations, or more precise acronyms, based on English language words. So both would fulfill the English language requirement and current practice to use this language as acronym source. But only LHHDT is consistent with the current practice for - 0:30 saving xHDT or xHST - 1:00 saving xDT or xST.
For any other locale, go to CLDR.
And, yes, this argues that implementations of the tzname[] array, and of strftime(), in UN*X systems should contain more code than just what you get with tzcode, so that it goes to the CLDR for time zone abbreviations for locales other than the C locale.
It would be convenient if strftime would return MEZ instead of CET. This might be even more important for non-Latin script writing systems. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Apr 15, 2013, at 6:47 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Tue, Apr 16, 2013 at 2:58 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Apr 15, 2013, at 7:59 AM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive@davros.org> wrote:
What we actually want to know is what Lord Howians actually use. Why? Me not. Localization is out of scope of the database. This belongs to CLDR.
Another way to think about this is to say
The abbreviations supplied by the tz database are the abbreviations appropriate for the C locale.
I guess "C locale" is not restricted Lord Howe English.
Well, according to International Standard ISO/IEC 9899, second edition 1999-12-01 (a/k/a "C99"), section 7.23.3.5 "The strftime function", paragraph 7: In the "C" locale, the E and O modifiers are ignored and the replacement strings for the following specifiers are: %a the first three characters of %A. %A one of ‘‘Sunday’’, ‘‘Monday’’, ... , ‘‘Saturday’’. %b the first three characters of %B. %B one of ‘‘January’’, ‘‘February’’, ... , ‘‘December’’. %c equivalent to ‘‘%a %b %e %T %Y’’. %p one of ‘‘AM’’ or ‘‘PM’’. %r equivalent to ‘‘%I:%M:%S %p’’. %x equivalent to ‘‘%m/%d/%y’’. %X equivalent to %T. %Z implementation-defined. so it's up to the implementation what to do for time zone names. I don't know whether C11 has specified more there. Annoyingly, the latest version of the Single UNIX Specification 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. which doesn't speak of LANG or LC_TIME. I *think* the idea is that if TZ is set to a POSIX-style string, the zone abbreviations are as specified in that string. If it's not (which, in theory, mean it should begin with a :, e.g. :America/Los_Angeles, although anything with tzcode-derived code will also interpret anything non-POSIX but *not* beginning with a : as a zone name as well), presumably the "implementation-dependent" in XBD "Environment Variables": 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. means it presumably could honor LANG or LC_TIME, i.e. the locale setting. So what time zone abbreviations you get in the C locale, if an Olson-database setting of TZ is used rather than a POSIX setting, doesn't appear to be specified by any current standard. (Is there even anything there requiring that the abbreviations be 3 characters or longer? The description of %Z seems to indicate that it could expand to a time zone name (Windows-style?): Z Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists. or expand to nothing at all if you don't have time zone information.
It would be convenient if strftime would return MEZ instead of CET.
Presumably meaning "in locales such as de_DE". In "en_{GB,AU,NZ,CA,US,etc.}", it would presumably return CET.
This might be even more important for non-Latin script writing systems.
The CLDR entries for China have what appear to be Chinese names/abbreviations, in Hanzi, for time zones.
Can I suggest that before we wade in and change time zone abbreviations we ought to step back and agree on what basis the abbreviations are set. This may be by a number of possible criteria, to name a few: - what is specified by the laws governing that area - what is in common place usage by the inhabitants of that area - creation of a unique and consistent time zone nomenclature, removing the inconsistencies of the above two methods - an arbitrary abbreviation for internal use by the TZ code and data that may approximate the above Also, we need to think through whether changes should be applied retrospectively or not, or whether perhaps we run a new set of abbreviations in parallel to the old ones, which become deprecated as they are replaced by the new ones. Unless we do this first, changes are likely to be made on the basis of who shouts loudest, regardless of any merit they may have, and as those promoting changes will each have their own agendas I would expect the naming to become even less consistent than it is. I don't use the abbreviations in my use of the database, so apart from having to dig through all of the noise that this debate generates on the mailing list it doesn't affect me much. But perhaps a good starting point would be to review how the time zone abbreviations in this project are currently used, and also what ISO and web standards there may already be for naming of time zones outside of this project, and decide whether we should aim to align with one of them. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Guy Harris Sent: 16 April 2013 04:51 To: tz@iana.org list Subject: Re: [tz] EST/EDT vs AEST/AEDT in AQ On Apr 15, 2013, at 6:47 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Tue, Apr 16, 2013 at 2:58 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Apr 15, 2013, at 7:59 AM, Tobias Conradi <mail.2012@tobiasconradi.com>
wrote:
On Mon, Apr 15, 2013 at 4:02 PM, Clive D.W. Feather <clive@davros.org> wrote:
What we actually want to know is what Lord Howians actually use. Why? Me not. Localization is out of scope of the database. This belongs to CLDR.
Another way to think about this is to say
The abbreviations supplied by the tz database are the abbreviations appropriate for the C locale.
I guess "C locale" is not restricted Lord Howe English.
Well, according to International Standard ISO/IEC 9899, second edition 1999-12-01 (a/k/a "C99"), section 7.23.3.5 "The strftime function", paragraph 7: In the "C" locale, the E and O modifiers are ignored and the replacement strings for the following specifiers are: %a the first three characters of %A. %A one of ''Sunday'', ''Monday'', ... , ''Saturday''. %b the first three characters of %B. %B one of ''January'', ''February'', ... , ''December''. %c equivalent to ''%a %b %e %T %Y''. %p one of ''AM'' or ''PM''. %r equivalent to ''%I:%M:%S %p''. %x equivalent to ''%m/%d/%y''. %X equivalent to %T. %Z implementation-defined. so it's up to the implementation what to do for time zone names. I don't know whether C11 has specified more there. Annoyingly, the latest version of the Single UNIX Specification 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. which doesn't speak of LANG or LC_TIME. I *think* the idea is that if TZ is set to a POSIX-style string, the zone abbreviations are as specified in that string. If it's not (which, in theory, mean it should begin with a :, e.g. :America/Los_Angeles, although anything with tzcode-derived code will also interpret anything non-POSIX but *not* beginning with a : as a zone name as well), presumably the "implementation-dependent" in XBD "Environment Variables": 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. means it presumably could honor LANG or LC_TIME, i.e. the locale setting. So what time zone abbreviations you get in the C locale, if an Olson-database setting of TZ is used rather than a POSIX setting, doesn't appear to be specified by any current standard. (Is there even anything there requiring that the abbreviations be 3 characters or longer? The description of %Z seems to indicate that it could expand to a time zone name (Windows-style?): Z Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists. or expand to nothing at all if you don't have time zone information.
It would be convenient if strftime would return MEZ instead of CET.
Presumably meaning "in locales such as de_DE". In "en_{GB,AU,NZ,CA,US,etc.}", it would presumably return CET.
This might be even more important for non-Latin script writing systems.
The CLDR entries for China have what appear to be Chinese names/abbreviations, in Hanzi, for time zones.
On Tue, Apr 16, 2013 at 9:14 AM, Tim Thornton <tt@smartcomsoftware.com> wrote: > Can I suggest that before we wade in and change time zone abbreviations we > ought to step back and agree on what basis the abbreviations are set. And documenting this in the Theory file may help in enforcement. > This may be by a number of possible criteria, to name a few: > - what is specified by the laws governing that area Does not work, there can be several esp. in multilingual countries. It will also involve Romanization for non-Latin script definition in single language countries, so increasing complexity. > - what is in common place usage by the inhabitants of that area Same as above. > - creation of a unique and consistent time zone nomenclature, removing the > inconsistencies of the above two methods Looks good and the current implementation - English language as source - ISO 3166-1 alpha-2 codes as source - structure in %s work in that direction > - an arbitrary abbreviation for internal use by the TZ code and data that > may approximate the above arbitrary and approximation seems to be contradictory to me. > Also, we need to think through whether changes should be applied > retrospectively or not, or whether perhaps we run a new set of abbreviations > in parallel to the old ones, which become deprecated as they are replaced by > the new ones. That would require tzcode change. > Unless we do this first, changes are likely to be made on the basis of who > shouts loudest, or what the TZ Coordinator likes most > regardless of any merit they may have, and as those > promoting changes will each have their own agendas I would expect the naming > to become even less consistent than it is. Depends on how much extra inconsistency the TZ Coordinator lets in. > I don't use the abbreviations in my use of the database, so apart from > having to dig through all of the noise that this debate generates on the > mailing list it doesn't affect me much. But perhaps a good starting point > would be to review how the time zone abbreviations in this project are > currently used, and also what ISO and web standards there may already be for > naming of time zones outside of this project, and decide whether we should > aim to align with one of them. On could also approach ISO and ask them to design a standard. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Tobias, I agree that it should be documented for future reference, otherwise we will just continue having these spats over naming approaches. You've made it clear that you effectively want a new naming system, which is one approach, but there are also arguments for aiming to meet legal names and common usage, even if these are not fully defined. There are also good arguments for not upsetting the apple cart, and sticking with the existin, working system. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. -----Original Message----- From: tobias.conradi@gmail.com [mailto:tobias.conradi@gmail.com] On Behalf Of Tobias Conradi Sent: 16 April 2013 12:56 To: Tim Thornton Cc: tz@iana.org Subject: Re: [tz] Time zone renaming overview On Tue, Apr 16, 2013 at 9:14 AM, Tim Thornton <tt@smartcomsoftware.com> wrote: > Can I suggest that before we wade in and change time zone > abbreviations we ought to step back and agree on what basis the abbreviations are set. And documenting this in the Theory file may help in enforcement. > This may be by a number of possible criteria, to name a few: > - what is specified by the laws governing that area Does not work, there can be several esp. in multilingual countries. It will also involve Romanization for non-Latin script definition in single language countries, so increasing complexity. > - what is in common place usage by the inhabitants of that area Same as above. > - creation of a unique and consistent time zone nomenclature, removing > the inconsistencies of the above two methods Looks good and the current implementation - English language as source - ISO 3166-1 alpha-2 codes as source - structure in %s work in that direction > - an arbitrary abbreviation for internal use by the TZ code and data > that may approximate the above arbitrary and approximation seems to be contradictory to me. > Also, we need to think through whether changes should be applied > retrospectively or not, or whether perhaps we run a new set of > abbreviations in parallel to the old ones, which become deprecated as > they are replaced by the new ones. That would require tzcode change. > Unless we do this first, changes are likely to be made on the basis of > who shouts loudest, or what the TZ Coordinator likes most > regardless of any merit they may have, and as those promoting changes > will each have their own agendas I would expect the naming to become > even less consistent than it is. Depends on how much extra inconsistency the TZ Coordinator lets in. > I don't use the abbreviations in my use of the database, so apart from > having to dig through all of the noise that this debate generates on > the mailing list it doesn't affect me much. But perhaps a good > starting point would be to review how the time zone abbreviations in > this project are currently used, and also what ISO and web standards > there may already be for naming of time zones outside of this project, > and decide whether we should aim to align with one of them. On could also approach ISO and ask them to design a standard. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Tue, Apr 16, 2013 at 2:04 PM, Tim Thornton <tt@smartcomsoftware.com> wrote:
You've made it clear that you effectively want a new naming system, which is one approach, but there are also arguments for aiming to meet legal names and common usage, even if these are not fully defined. Aiming and failing. English speaking countries might have it OK for them. But maybe here IANA does not care about other languages as much as about English.
There are also good arguments for not upsetting the apple cart, and sticking with the existin, working system. Working for English speaking countries, except Australia, not working for languages other than English and failing for some countries, e.g. Indonesia with English WIT Western Indonesia Time which conflicts with local Indonesian WIT Waktu Indonesia Timur (Time Indonesia East).
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Apr 16, 2013, at 5:59 AM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
Working for English speaking countries, except Australia, not working for languages other than English and failing for some countries, e.g. Indonesia with English WIT Western Indonesia Time which conflicts with local Indonesian WIT Waktu Indonesia Timur (Time Indonesia East).
If we follow my suggestion that we think about the time zone abbreviations *we* supply - as opposed to the ones the CLDR supplies - as being the abbreviations in the "C" locale (when the TZ environment variable isn't set to a POSIX value, because those explicitly specify the abbreviations in the environment variable's value), the question is what should language should the "C" locale version of the time zone abbreviations reflect? English? (What abbreviations do English speakers living in Indonesia, or involved with Indonesia and speaking about times of events in Indonesia with time zone indications, use?) The local language, if it uses the Roman alphabet? The local language, even if it *doesn't* use the Roman alphabet?
On Sat, Apr 13, 2013 at 2:48 AM, Gwillim Law <gwillim@gmail.com> wrote:
When I was a data administrator, one of the most fundamental principles I learned was not to try to embed one field as a code inside another one. For example, most Austrian postal codes allow you to infer the state from the first digit. The postal code 5016 is in Salzburg; Koppl is 5321; Tenneck is 5451; they're all in Land Salzburg. So why not use the postal code field to figure out which state a place is in? Because sooner or later, someone will change the system. (In fact, there are already a few exceptions in the case of Austria.) If you look at http://commons.wikimedia.org/wiki/File:2_digit_postcode_austria.png you can see the codes are organized, the first digit gives a larger region, the first two a smaller one.
The postal code designers did exactly what you "learned" not to do.
I believe that the same principle applies to tz abbreviations. If programmers get the idea that they can rely on the next-to-last letter of the tz abbreviation to represent the offset from standard time, with H = .5 and D = 1, at least a few of them will start writing code that makes that assumption. (Some programmers love to think up tricks like that, in order to save a line or two of code.) It's just not a good data design. The tz database contains a field that's defined as the offset from standard time, and it's expressed as a time, not a letter code. Force the programmers to use that field. Never suggest that the next-to-last letter can be used instead. One of the reasons for not using D in %s for anything else than 1:00 saving is, to reduce the chance for ambiguity if 0:30 saving and 1:00 exist in one region at the same time, or at different times in the same year.
The Austrian postal codes designer fixed one digit for one area (e.g. 6), so that with the next digit they did not have to care about collisions within another region (e.g. 7). Systematization and globally time point unique abbreviations have benefits, that are not reduced by programmers do their personal programming. It can happen all the time that a programmer codes against unspecified behavior. That doesn't mean specified behavior has to stop. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 12 April 2013 04:45, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
D for %s never means anything else than 1:00 saving.
Within the current tz database, sure, that is presently the case. But this is not necessarily the case within ACTUAL practice; "D" could conceivably be used to refer to a DST offset of any amount, since it is still "daylight saving time", just of a different amount. I am not making the argument here that the terminology is used this way in Australia/Lord_Howe; only that if it is, then LHDT is a perfectly suitable (and indeed, preferred) abbreviation for UTC+10:30+0:30 as observed there in the summer. To be clear, I haven't seen any evidence either way, but I don't particularly believe any residents of Lord Howe Island would call it "Lord Howe half-daylight time", because to them, half an hour is a full transition. Granted, this has not always been the case (see four summers from 1981–1982 to 1984–1985), but I suspect residents understood it as a change to "daylight saving time" itself, while still referring to it in the same way. Whatever the case, we should reflect the terminology in use, and not aim for anything more. On 12 April 2013 08:38, <random832@fastmail.us> wrote:
You are inferring a systematism where non exists.
Precisely. On 12 April 2013 04:22, Tobias Conradi <tobias.conradi@gmail.com> wrote:
We are not inventing anything new It has been proven you do in the scope of the DB.
I have not been part of this project for very long, but I believe most of the "invented" abbreviations have been simply to fulfill POSIX requirements where no commonly-used English terminology previously existed. In the case of Australia/Lord_Howe, one would presume that such terminology already exists, so we should use that, whatever it is. -- Tim Parenti
On Fri, Apr 12, 2013 at 4:40 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 12 April 2013 04:45, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
D for %s never means anything else than 1:00 saving.
Within the current tz database, sure, that is presently the case. But this is not necessarily the case within ACTUAL practice;
Sure, actual practice in the IANA time zone database.
"D" could conceivably be used to refer to a DST offset of any amount, since it is still "daylight saving time", just of a different amount. Against actual practice in the IANA time zone database, deteriorating usability for those that rely use systematization.
I am not making the argument here that the terminology is used this way in Australia/Lord_Howe; only that if it is, then LHDT is a perfectly suitable (and indeed, preferred) abbreviation for UTC+10:30+0:30 as observed there in the summer. Why? For other regions the database does not care at all about local usage and will certainly fail in bilingual environments.
To be clear, I haven't seen any evidence either way, but I don't particularly believe any residents of Lord Howe Island would call it "Lord Howe half-daylight time", because to them, half an hour is a full transition. Does that matter?
Granted, this has not always been the case (see four summers from 1981–1982 to 1984–1985), but I suspect residents understood it as a change to "daylight saving time" itself, while still referring to it in the same way. Whatever the case, we should reflect the terminology in use, and not aim for anything more. Oh, why that? And how can that be applied to abbreviations for newly created zones?
On 12 April 2013 08:38, <random832@fastmail.us> wrote:
You are inferring a systematism where non exists.
Precisely. Contradicting your own "Within the current tz database, sure, that is presently the case. "
On 12 April 2013 04:22, Tobias Conradi <tobias.conradi@gmail.com> wrote:
We are not inventing anything new It has been proven you do in the scope of the DB.
I have not been part of this project for very long, but I believe most of the "invented" abbreviations have been simply to fulfill POSIX requirements where no commonly-used English terminology previously existed. POSIX requirements for abbreviations can be fulfilled without English terminology. E.g. WIT could mean Waktu Indonesia Timur (Eastern Indonesian Time) instead of IANA used English Western Indonesia Time.
The English speaking countries largely get their way through with locally used abbreviations, whilst needs and wishes of others are ignored. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 12 April 2013 10:57, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Fri, Apr 12, 2013 at 4:40 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 12 April 2013 04:45, Tobias Conradi <mail.2012@tobiasconradi.com>
wrote:
D for %s never means anything else than 1:00 saving.
Within the current tz database, sure, that is presently the case. But this is not necessarily the case within ACTUAL practice; Sure, actual practice in the IANA time zone database.
"D" could conceivably be used to refer to a DST offset of any amount, since it is still "daylight saving time", just of a different amount. Against actual practice in the IANA time zone database, deteriorating usability for those that rely use systematization.
It would appear you misunderstood or misinterpreted my statements. The ONLY "actual practice" which is relevant is the actual practice on the ground, independent of tz. If I understood your statement correctly, this is the opposite of what you said.
To be clear, I haven't seen any evidence either way, but I don't particularly believe any residents of Lord Howe Island would call it "Lord Howe half-daylight time", because to them, half an hour is a full transition. Does that matter?
As above, yes. What the locals call it should be the ONLY practice that matters. While I am sympathetic to your desires for broader systematization, it is not the aim of this project.
I am not making the argument here that the terminology is used this way in Australia/Lord_Howe; only that if it is, then LHDT is a perfectly suitable (and indeed, preferred) abbreviation for UTC+10:30+0:30 as observed there in the summer. Why? For other regions the database does not care at all about local usage and will certainly fail in bilingual environments.
On 12 April 2013 04:22, Tobias Conradi <tobias.conradi@gmail.com> wrote:
We are not inventing anything new It has been proven you do in the scope of the DB.
I have not been part of this project for very long, but I believe most of the "invented" abbreviations have been simply to fulfill POSIX requirements where no commonly-used English terminology previously existed. POSIX requirements for abbreviations can be fulfilled without English terminology. E.g. WIT could mean Waktu Indonesia Timur (Eastern Indonesian Time) instead of IANA used English Western Indonesia Time.
The English speaking countries largely get their way through with locally used abbreviations, whilst needs and wishes of others are ignored.
Again, I haven't been around for long, but according to my understanding of this project's history, it is solely an English-language project. Localization issues are outside of its scope. -- Tim Parenti
On Fri, Apr 12, 2013 at 5:20 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 12 April 2013 10:57, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
Against actual practice in the IANA time zone database, deteriorating usability for those that rely use systematization.
It would appear you misunderstood or misinterpreted my statements. The ONLY "actual practice" which is relevant is the actual practice on the ground, independent of tz.
How did you came to this conclusion?
To be clear, I haven't seen any evidence either way, but I don't particularly believe any residents of Lord Howe Island would call it "Lord Howe half-daylight time", because to them, half an hour is a full transition. Does that matter?
As above, yes. What the locals call it should be the ONLY practice that matters. This is not current practice. All non-English abbreviations used by locals are simply ignored, leading to WIT in the database meaning Western Indonesia Time, whilst to locals it means Eastern Indonesia Time.
While I am sympathetic to your desires for broader systematization, it is not the aim of this project. %s is systematized so that "D" never means anything else than 1:00 saving time.
The English speaking countries largely get their way through with locally used abbreviations, whilst needs and wishes of others are ignored.
Again, I haven't been around for long, but according to my understanding of this project's history, it is solely an English-language project. At least it is since some months an IANA project. The IANA site states
http://www.iana.org/about "The Internet Assigned Numbers Authority (IANA) is a department of ICANN" The ICANN site http://www.icann.org/en/about/welcome "Welcome to ICANN’s global community supporting the vision of "one world, one Internet." " http://www.icann.org/en/about/governance/guidelines "The mission of ICANN is to coordinate, at the overall level, the global Internet's systems of unique identifiers"
Localization issues are outside of its scope. That's my proposal: stop localizing to English.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 2013-04-12 15:57, Tobias Conradi wrote:
POSIX requirements for abbreviations can be fulfilled without English terminology. E.g. WIT could mean Waktu Indonesia Timur (Eastern Indonesian Time) instead of IANA used English Western Indonesia Time.
The "Theory" file says "Use abbreviations that are in common use among English-speakers". I don't know if that means world-wide or within the region it applies to.
The English speaking countries largely get their way through with locally used abbreviations, whilst needs and wishes of others are ignored.
Traditionally, system text in the default "POSIX" (or "C") locale is in US English, although I don't think that's a POSIX requirement. (The character set may limit the options as I think it's limited to ASCII, although I believe there is some debate about whether LC_CTYPE="POSIX" allows UTF-8 encoded messages or not.) The POSIX standards and ISO C standards do not mention localization at all for the "%Z" format-specifier of strftime() (or other places where a timezone abbreviation could appear), but do specifically state that output for various other strftime() format-specifiers is localized. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Fri, Apr 12, 2013, at 10:57, Tobias Conradi wrote:
On 12 April 2013 08:38, <random832@fastmail.us> wrote:
You are inferring a systematism where non exists.
Precisely. Contradicting your own "Within the current tz database, sure, that is presently the case. "
If the tz database consisted of only US timezones, it would be true "within the current tz database" that daylight savings is always D (or W or P) and never S (which means Standard time). That doesn't mean there is a rule that it always _has to be_ one of those letters.
On Fri, Apr 12, 2013 at 7:07 PM, <random832@fastmail.us> wrote:
On Fri, Apr 12, 2013, at 10:57, Tobias Conradi wrote:
On 12 April 2013 08:38, <random832@fastmail.us> wrote:
You are inferring a systematism where non exists.
Precisely. Contradicting your own "Within the current tz database, sure, that is presently the case. "
If the tz database consisted of only US timezones, it would be true "within the current tz database" that daylight savings is always D (or W or P) and never S (which means Standard time). That doesn't mean there is a rule that it always _has to be_ one of those letters. Did anyone claim anything to the opposite? If so, could you post the link to that message in the email archive?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Wed, Apr 17, 2013, at 13:58, Tobias Conradi wrote:
Did anyone claim anything to the opposite? If so, could you post the link to that message in the email archive?
Er. Your whole line of argument with this LHHT thing has been that any random fact (e.g. D always means 1:00 and not 0:30) that happens to be true of the data today is a standard that must be adhered to.
On Wed, Apr 17, 2013 at 8:03 PM, <random832@fastmail.us> wrote:
On Wed, Apr 17, 2013, at 13:58, Tobias Conradi wrote:
Did anyone claim anything to the opposite? If so, could you post the link to that message in the email archive?
Er. Your whole line of argument with this LHHT thing has been that any random fact (e.g. D always means 1:00 and not 0:30) that happens to be true of the data today is a standard that must be adhered to. No, I didn't claim that the consistent usage of D in %s is a random fact. And what you write now differs from your statement that I commented, but you deleted: --------part 1-----------
If the tz database consisted of only US timezones, it would be true "within the current tz database" that daylight savings is always D (or W or P) and never S (which means Standard time). Did anyone claim something different?
--------part 2-----------
That doesn't mean there is a rule that it always _has to be_ one of those letters. Did anyone claim there is such a rule?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Wed, Apr 17, 2013, at 14:16, Tobias Conradi wrote:
No, I didn't claim that the consistent usage of D in %s is a random fact.
I didn't say you claimed it was a random fact, I said it _is_ a random fact. You based your entire argument for this LHHT invention on nothing else but that it happens to be true of the data that exists now. There's nothing in Theory that says abbreviations with D must mean 1:00.
On Wed, Apr 17, 2013 at 8:23 PM, <random832@fastmail.us> wrote:
On Wed, Apr 17, 2013, at 14:16, Tobias Conradi wrote:
No, I didn't claim that the consistent usage of D in %s is a random fact.
I didn't say you claimed it was a random fact, I said it _is_ a random fact. How do you came to this conclusion?
You based your entire argument for this LHHT invention on nothing else but that it happens to be true of the data that exists now. Not true. I mentioned it already, using LHDT for 0:30 /and/ for 1:00 saving may lead to ambiguities, e.g. if two time records with one of the offsets each are displayed next to each other.
I did invent LHHT without knowing about xHDT usage in the database. When I found out about the wide usage of HD I changed my proposal to LHHDT.
There's nothing in Theory that says abbreviations with D must mean 1:00. It's in Practice.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 17/04/2013 19:36, Tobias Conradi wrote:
On Wed, Apr 17, 2013 at 8:23 PM, <random832@fastmail.us> wrote:
On Wed, Apr 17, 2013, at 14:16, Tobias Conradi wrote:
No, I didn't claim that the consistent usage of D in %s is a random fact.
I didn't say you claimed it was a random fact, I said it _is_ a random fact. How do you came to this conclusion?
You based your entire argument for this LHHT invention on nothing else but that it happens to be true of the data that exists now. Not true. I mentioned it already, using LHDT for 0:30 /and/ for 1:00 saving may lead to ambiguities, e.g. if two time records with one of the offsets each are displayed next to each other.
But as long as both 0:30 and 1:00 offsets weren't in use at the same time, and you know the history, you can work out which one was used for any particular timestamp.
I did invent LHHT without knowing about xHDT usage in the database. When I found out about the wide usage of HD I changed my proposal to LHHDT.
There's nothing in Theory that says abbreviations with D must mean 1:00. It's in Practice.
-- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Wed, Apr 17, 2013, at 14:36, Tobias Conradi wrote:
There's nothing in Theory that says abbreviations with D must mean 1:00. It's in Practice.
Are we five now? Oh, look! A wild 404 error appears: https://raw.github.com/eggert/tz/master/Practice You knew _exactly_ what I meant when I capitalized Theory.
On Wed, Apr 17, 2013, at 14:16, Tobias Conradi wrote:
That doesn't mean there is a rule that it always _has to be_ one of those letters. Did anyone claim there is such a rule?
My entire point is that hypothetical "rule" is OF EQUAL STATUS to your "anything with a D must be 1:00" rule. There's no more basis for one than for the other, other than that one of them suits your agenda and the other does not.
On Wed, Apr 17, 2013 at 8:24 PM, <random832@fastmail.us> wrote:
On Wed, Apr 17, 2013, at 14:16, Tobias Conradi wrote:
That doesn't mean there is a rule that it always _has to be_ one of those letters. Did anyone claim there is such a rule?
My entire point is that hypothetical "rule" is OF EQUAL STATUS to your "anything with a D must be 1:00" rule. That is a different claim.
There's no more basis for one than for the other, other than that one of them suits your agenda and the other does not. And one of them is important to avoid ambiguity (D means 1:00) and the other (1:00 has to be D) is not.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
participants (13)
-
Clive D.W. Feather -
Derick Rethans -
Guy Harris -
Gwillim Law -
Ian Abbott -
John Hawkinson -
John Haxby -
Paul Eggert -
random832＠fastmail.us -
Tim Parenti -
Tim Thornton -
Timothy Arceri -
Tobias Conradi