Jump to content

Template talk:Time zone

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Dealing with time zones which have the same code

[edit]

Some time zones have the same codes. For example, Irish Summer Time and Indian Standard Time.Galmicmi (talk) 13:24, 11 December 2009 (UTC)[reply]

I propose to use exceptions when codes are the same but time zones are differents. For example, put the name of the continent after the code. - Galmicmi (talk) 13:37, 11 December 2009 (UTC)[reply]
Irish Summer Time : {{tz|IST}} : {{tz|IST}}
Indian Standard Time : {{tz|IST-Asia}} : {{tz|IST-Asia}}

I'd rather go with just one short alternative for the lesser-used option. IST almost always means Indian Summer Time, so have IST and IrST. Chris Cunningham (not at work) - talk 15:25, 11 December 2009 (UTC)[reply]
Time zones abbreviations are official. We can't change them. Either we change the template model completely, either we uses exceptions but we need to keep the existing abbreviations. On www.timeanddate.com, they make the distinction between abbrevations using continent name (Europe, Australia, North America). But, you're right, if we need to change something, it must be done on the lesser-used option.Galmicmi (talk) 22:26, 11 December 2009 (UTC)[reply]
Okay, but I'd still rather go with the easiest option to type - such as "IST E" rather than "IST (Europe)". This is, after all, intended to save editors time. Chris Cunningham (not at work) - talk 00:39, 12 December 2009 (UTC)[reply]
I've added a box for the exceptions following your advice. We will see how people will deal with it.Galmicmi (talk) 09:26, 12 December 2009 (UTC)[reply]

Tz database

[edit]

I suggest to add data from the tz database to sub templates. The data from the four columns of the zone file could be stored accessible via the TZ variable in three templates:

TimeCurrency (talk) 18:08, 9 March 2010 (UTC)[reply]

I added the data and created an infobox template:tz/infobox to be used in the individual tz zone pages. Now it would be good to add the acronyms too, e.g. at template:tz/accronyms TimeCurrency (talk) 17:02, 10 March 2010 (UTC)[reply]

Ideas to improve the template

[edit]

It appears that only few articles use this template, see [1]. I think the reason is that nobody can be sure if an abbreviation will stay in time. The template should be improved to ensure that an abbreviation will "never" change. Has someone any idea how it should be done? - Galmicmi (talk) 19:42, 14 July 2010 (UTC)[reply]

Personally, I would use ISO 3166-1 alpha-3 instead of time zones abbreviations, but i'm not sure if it is suitable as we are used to time zone abbreviations. The code could take as input a ISO 3166-1 alpha-3 code and the result would be displayed using time zone abbreviations. - Galmicmi (talk) 20:10, 14 July 2010 (UTC)[reply]
It's got few transclusions because most of the intended use cases (country infoboxes) are already filled in, and most people don't go looking for templates for things like this unless they already know they exist. As such I think the basic premise here is wrong, and I haven't a clue why an {{under construction}} tag was placed on it. As for the suggestion to take completely different input, that's something for a different template to cope with. Chris Cunningham (not at work) - talk 09:01, 15 July 2010 (UTC)[reply]
When using time zones abbreviations, there are many cases where two different time zones have the same abbreviation and it complicates things as we must have an unique identifier for a time zone. For example, CST can be used for [Central Standard Time] and [China Standard Time]. If we want to stay neutral, using the criteria of biggest population for the shortest time zone will imply to use CST for [China Standard Time] and CST NA for [Central Standard Time]. Some won't agree with this nomenclature as Wikipedia EN is mainly edited by Americans. So, either you keep a template which is incomplete; either you use another form. Concerning the use of a different template in the case another type of input is used, i think you are right; it would let people to choose which template is the best. I placed a tag {{under construction}} because I think if a template that could be very usefull has been rarely used in seven months, it means that there is something wrong- Galmicmi (talk) 16:11, 15 July 2010 (UTC)[reply]
I already explained why it has limited transclusions: it's of limited utility, and will only gradually be added to existing articles. Your suggested alternative really looks like a solution looking for a problem to me. Chris Cunningham (not at work) - talk 11:05, 16 July 2010 (UTC)[reply]
I agree with Chris really – the task this template performs had already been done manually on most articles. Also the template is still new-ish, and it takes while for word to get around, especially when the template does its job relatively invisibly. In any case, my recommendation would be for this template ultimately to have no transclusions. I think it should be modified to do the same kind of trickery as {{Nfa}}, which is intended to be subst'd. The way that template is designed ensures that only the text required for the desired output gets subst'd, rather than all of the switch statements (substing {{tz}} at the moment would be a very bad idea. If we redesigned the template with subst'ing in mind, and recommend it be used that way, Galmici's concern about abbreviations not changing will be put at ease.
Furthermore, I wouldn't advocate the use of ISO-3166 codes, in this or another template, as it doesn't make things any easier. You would still need additional parameters to cover DST and countries with more than one time zone, which would arguably be more complex than the way things currently work. AJCham 17:25, 16 July 2010 (UTC)[reply]
After far more fannying about than ought to have been necessary, I've created a test version of Tz at User:AJCham/Tz which works in the same way as {{Nfa}}. I'm not 100% certain that the code subpage is required for this solution to work, but I followed the lead of that other template anyway. I would have been bold and implemented the new version if but for one issue – the test version must be subst'd to work properly. Even though I think the template ought to be used this way, I'm sure there must be a method to make it behave as expected if it is transcluded, if for no other reason than to avoid making a mess where it is already being used. AJCham 18:22, 16 July 2010 (UTC)[reply]
In general I'm pretty firmly opposed to substitution-only templates: the number of times over the years that a subst-only template has later been improved (which means that only new instances pick up on the fixes) makes me very cautious of doing the same here. (FWIW {{nfa}}'s cousin {{fc}} is an excellent example of this, as if the project ever decides to drop the dots from "F.C." we'd have been far better off not substituting them.) Chris Cunningham (not at work) - talk 18:35, 16 July 2010 (UTC)[reply]
I understand where you are coming from, and in its primary use in infoboxes transclusion probably isn't so bad. I was introduced to this template when using {{footballbox_collapsible}}, the doc page of which advocates its use. On pages such as the ones I've been working on, I've used {{tz}} dozens or even hundreds of times per page, which causes a lot of data to be transcluded for very little gain. How much is this template likely to change that there would be a noticeable downside to my having subst'd it? On that basis I think it would be a good idea to have a substitution as an option, either by making this template act appropriately depending on whether it was transcluded or subst'd, or, if that is not possible, having a second template ({{tz2}}?) alongside it. If the latter is the only viable option I think it would be beneficial that the two templates share some base code so that they will always produce the same output when used, and only one page would need to be updated when changes are made. Sadly I'm now getting beyond my comfort zone with the intricacies of templates so would to defer to someone more template-savvy than I for ideas on how this might be accomplished. AJCham 19:24, 16 July 2010 (UTC)[reply]
I think of one thing, why do we complicate ? ISO 8601 doesn't use abbreviations. We could only keep the default values (for example {{tz|-06}} for {{tz|-06}})<nowiki>. It is not exactly like [[ISO 8601]] which does not print UTC, but at least, it gives a constant format, which is not about to change.- [[User:Galmicmi|Galmicmi]] ([[User talk:Galmicmi|talk]]) 21:48, 16 July 2010 (UTC) {{outdent|:::::::::}}We complicate it here to make things less complicated elsewhere – that's one of the benefits of having templates. Believe me, compared to some other templates (some of which are amongst our most frequently used) this template is far from complicated. Anyway, a template as simple as the one you are now proposing seems pointless to me. At the moment I might use {{tlp|tz|-06}} occasionally for the sake of consistency when I am using {{tlp|tz|XXX}} elsewhere in the article. But if the other functionality is removed, why would I prefer the template over simply typing <nowiki>[[UTC−06]]? Also, the link to the timezone is at least as important as the UTC offset, IMO. AJCham 22:52, 16 July 2010 (UTC)[reply]
Finally, I think using substitution is the best solution. At least, template can be changed at any time without breaking previous editions on articles where it was used, it gives the opportunity to the template to evolve, it allows a near constant format, and at the end someone can always change an article without fearing to break links on others articles. - Galmicmi (talk) 18:26, 19 July 2010 (UTC)[reply]

Los Angeles vs. Los_Angeles

[edit]

Please refer to comment/inquiry at Talk:America/Los Angeles#Los Angeles vs. Los_Angeles. Thanks. — Ipoellet (talk) 16:33, 8 July 2012 (UTC)[reply]

Philippine Time

[edit]

This table is wrong. Philippine time is PHT, not PST AS

http://www.timeanddate.com/library/abbreviations/timezones/asia/pht.html

John of Cromer in China (talk) mytime= Mon 17:01, wikitime= 09:01, 19 November 2012 (UTC)[reply]