Template talk:Places by decade

Ideas

Microformats

hcalendar might be used for autogenerating hcard info on categories using this template? -J JMesserly (talk) 19:56, 12 January 2009 (UTC)[reply]

This currently works. Users of Firefox may install the Operator extension and verify locations by clicking on Operator's button for Google or Yahoo Maps. -J JMesserly (talk) 20:31, 23 January 2009 (UTC)[reply]

It's great to see microformats being used, but I'm not clear why it's being used in the way that it is. For example, File:Jungfernbrücke Baluschek.png is now tagged with the date "1205-06-15", despite showing a post-industrial urban scene; and that date does not appear anywhere in the text of the image's page. Similarly, the page is emitting hCard microformats with address details that do not appear on the page, and a broken Geo microformat. Why does the template have hard-coded references to "Avenue des Champs-Élysées" and other places? And why is File:Paris1944.jpg date-stamped with a time of midnight, and "Arc_de_Triomphe_de_l'Étoile" marked up as the name of a person? If you can document how the template is/ is supposed to work, then I'll try to assist, but it's currently not clear from the documentation we do have. Andy Mabbett (talk) 14:38, 24 January 2009 (UTC)[reply]

Thank you for your interest in vEvents on Commons.

The docs for Template:Places by decade#parameter list and Template:Events by decade#parameter list clearly state what the first second and third parameters are and give examples of their use. You may also be interested in Template:Places by decade/faq. Many of your high level observations eg. utility of hcalendar for historical periods are probably mentioned there. If you want to go into greater depth, please let me know. To be honest, you are the first one to ask, and certainly won't be the last. I know that over on the microformats.org site their are lots of folks that metadata types should be specialized. If you are aware of these discussions, I am a minimalist- that is, of the school that existing formats should be employed as much as possible unless there is some clear need to invent something new.
Did you look at the template for File:Jungfernbrücke Baluschek.png? It had the code:
```
{{places by decade|Bezirk Mitte|1200|closest=Berlin-Mitte|near=Bezirk Mitte|far=Berlin}}
```
. This clearly indicates the decade starting in the year 1200, so looks like a typo to me. I don't know what date was intended for the bridge. When a decade but not exact date is mentioned, a start date of the middle of the decade is indicated. For categories, a date range could be indicated in it's place eg dtStart of first day of decade, with dtend at last day of a century. For images, for example a painting whose exact date intended may not be known, it would be best if the author took a stab at specifying date=, but if not the default seems middle of decade seems reasonable to me. The correct coding for the date of the bridge is probably something like:
```
{{places by decade|Bezirk Mitte|1920|Jungfernbrücke|date=1926-01-01}} 
```
. I corrected the typo. If you click on google maps, it will take you to the bridge, because Jungfernbrucke is a placename it recognizes. Much easier than geo coord no?
File:Paris1944.jpg is coded
```
{{events by decade|Paris VIIIe arrondissement|1940|Arc_de_Triomphe_de_l'Étoile|event=Paris Liberation|date=1944-08-25|}}
```
The time code allows specification of timepoint to the accuracy of tenths of second. I don't imagine we have that level of accuracy for any matererial on Commons, but if folks want to specify it, I'll add the ability. Definition of dtEnd is exclusive, so dtStart if estimated must go to the very beginning of the period, which is midnight, the very start of the day.
Re: broken Geo format: Yahoo and Google maps work fine with the metadata provided. I formerly provided geo coord but that data was ignored and besides, overlapped with the geocoding folks. There is an overlap because event requires place. Earlier, I was not emitting hCard at all. It is useful for authoring, so it's there, and I noted the distinction on the geoCoding talk page. This particular issue (if you have one) might best be discussed there. If all pages used template:location, then it should be removed as redundant. I could certainly put in a flag to suppress it when the location template is present, or if the map applications give misleading results.
-J JMesserly (talk) 16:51, 24 January 2009 (UTC)[reply]

Thank you for your lengthy response. Firstly, to clear up any misunderstandings, I am extremely familiar with microformats; I initiated the Wikipedia-en project and added microformats to the vast majority of the templates now using them. I've been involved in the development of both Operator and Swignition (formerly Cognition) parsers.

I've read the /doc page for this template, but it doesn't answer my questions; I hadn't seen the FAQ; and there doesn't appear to be a link to it from the template's documentation. I didn't mention the "utility of hcalendar for historical periods", though I am aware of concerns about the difference between Julian and Gregoraian dates (generally pre-1750). Unfortunately, I don't see what you mean by your "microformats.org … I'm a minimalist … invent something new" comment. Your presumption of a more-specific middle-of-the decade date for something where only a decade is specified seems to be unsupported by the relevant standards and specifications; a date of "1926-01-01" explicitly means "after 1925-12-31 and before 1926-01-02".

"Jungfernbrucke" may be "much easier than geo coord"; but what if the place is "a boat in the middle of the Atlantic ocean", or "Newtown", or some other ambiguous value? File:Jungfernbrücke Baluschek.png is currently emitting an invalid geo microformat: }". Events microformats (hCalendar) do not require a place; the "location" property is optional.

My point about the date in File:Paris1944.jpg is that it is over-precise, and thus bogus. A date in format YYYY-MM-DD is allowable (as is YYYY-MM or just YYYY). There is no need to estimate either a start or end date. Andy Mabbett (talk) 19:12, 24 January 2009 (UTC)[reply]

Furthermore, in these edits, you introduce a metadata date of 1941-01-01; when the image concerned is clearly dated 1941-01-31. I contend that such behaviour is harmful, and request that you desist, and indeed reverse them, until such time as the template is able to handle specific dates, with am appropriate level of precision.

I've made a start, by removing the hCard mark-up from the {{Place/doVEvent}} sub-template - its not appropriate for many images. On further examination, it would seem best to apply hCalendar and geo microformats using {{Information}}; and to use this template to apply the decade/ location categories separately. Accordingly, please see Template talk:Information#Adding hCalendar microformat. Of course, I'm open to alternative suggestions. Andy Mabbett (talk) 00:39, 25 January 2009 (UTC)[reply]

Your "fix" broke the template and has been reverted. This is an experimental template, and your largely theoretical objectiona are academic and the edits based on them are unwelcome. It is disruptive, and unproductive. If you can get concensus with the geocoding crowd that what I am doing is incorrect, I will accept their judgement. However judging from your history, I have no intention of wasting time debating purism of semantic encoding rather than writing code that actually delivers the semantic net. -J JMesserly (talk) 01:11, 25 January 2009 (UTC)[reply]

My fix didn't break the template; it removed some of the most broken parts it had originally (if you believe otherwise, please explain why it was emitting }"); and your your edit summary was an unwarranted ad-hominem attack. You refer to the template as "experimental", yet are adding it to live pages with inappropriate metadata; and my observations are not "theoretical", but based on the extensive experience described above; as to them being "unwelcome", who are you to say that? Andy Mabbett (talk) 01:19, 25 January 2009 (UTC)[reply]

Well, if you had observed the results of your "fix", you would see that it makes a mess of the pages using the template. Take a look at the calendar icon text area. I have no intention of engaging in theoretical debate with you. I propose you convince an impartial microformats body such as the GeoCoding project of the rightness of your positions, and I will be happy to follow their judgement. -J JMesserly (talk) 01:51, 25 January 2009 (UTC)[reply]

You appear to be unwilling to engage in any debate. Nonetheless, I repeat my question: why have you just reverted this template to a version which emits "}""? Why have you reverted to version which emits metadata that asserts that File:Blaachard Napoleon.jpg is about a person whose given-name is "Rond" and whose family-name is "Point"? And whose locality (as explicitly distinct from a smaller street-address or larger region) is "Rond Point, Avenue des Champs-Élysées, Paris, Île-de-France"? And from where do you get the information that File:Jean Béraud Les Grands Boulevards Le Theatre Des Varietes.jpg was created on 15 June 1885 exactly, when the file's page simply says 1875-90s ? These are, again, not "largely theoretical objections" but hard, factual matters,a bout metadata you are adding to live pages. Andy Mabbett (talk) 02:06, 25 January 2009 (UTC)[reply]

I have now resolved the issue of the extraneous code which you note on my talk page, and which was caused by you not having closed a span. The edit summary of your intermediate revert, "reverting vandalism by Pigsonthewing" was unacceptable. Andy Mabbett (talk) 02:18, 25 January 2009 (UTC)[reply]

You are breaking interoperability with Yahoo and google maps using Firefox's operator extenstion. If you want to have a template that doesn't interoperate, you are free to create one, or copy this code to do it. Removal of functionality on this set of templates is vandalism. -J JMesserly (talk) 02:41, 25 January 2009 (UTC)[reply]

I have broken no interoperability, using any microformats parser. I have, though, removed broken and bogus mark-up. Your fallacious accusations of vandalism remain unacceptable, and are beginning to appear malicious. Please now address my points in my last-but-one comment, above. Andy Mabbett (talk) 02:47, 25 January 2009 (UTC)[reply]

Please explain why after your "Fix", that Google and Yahoo map buttons don't work anymore using Firefox's Operator toolbar. Call it what you will, you are removing functionality. Please desist. -J JMesserly (talk) 02:50, 25 January 2009 (UTC)[reply]

And I'm again reverted with another ad hominem edit summary, accusing me of vandalism, and asserting that this is J JMesserly's template. Andy Mabbett (talk) 02:50, 25 January 2009 (UTC)[reply]

Let's not personalize this. It is vandalism because you are removing functionality. -J JMesserly (talk) 02:53, 25 January 2009 (UTC)[reply]

It is you who has chosen to personalise this; by making ad hominem attacks in your edit sumamries; not I. And it is you who has asserted that this template is yours. Andy Mabbett (talk) 02:55, 25 January 2009 (UTC)[reply]

Andy, the issue is you are removing valuable functionality from a template that has only been in existence for a few weeks, is currently undergoing development, and is not widely used on Commons. Further, you know that you are making a controversial change that you did not seek concensus on. It is unclear why you do not simply create another template with the functionality you desire. -J JMesserly (talk) 03:00, 25 January 2009 (UTC)[reply]

Gentlemen

I found this via the user problems noticeboard and read through the above discussion your talk pages.

It seems to me that you've both mis-stepped where you could have shown more consideration and understanding. J JMesserly has stated that the template is experimental. Invalid code is ther and that it is emitting invalid code is hopefully a temporary state that will be sorted out in due course. Demanding or implementing changes for which there is clearly not consensus is not productive.

That said, maybe it would be better to iron out the kinks on test-images before implementing this template on actual files.

As for language used, calling edits that seem to be made with best intentions "vandalism" is unfair. This discussion would be well served if you were to approach it with an assumption of good faith. Reverts may be frustrating but, as has been pointed out, the template is experimental. It is in active development and every revision is in the edit history.

If you can work things out here on the talk page and then import changes into the template, then great. If not, creating versions for each approach is better than battling things out here. Different templates can showcase different solutions and once they become stable, the community can decide which is more useful for the purpose of Commons. That, however, will be a painful process for both of you and will inevitably require compromises. I suggest you start preparing now. Not for a battle, but for the make-up. Stay cool. --Swift (talk) 05:07, 25 January 2009 (UTC)[reply]

Thanks. I was indeed too quick to label something as vandalism. I am happy adhere to Swift's proposal. Different templates are perfectly acceptable. Andy, once you have whatever features/ fixes you want added to your copy of the template, I will endeavor to reach consensus with you on merging the changes. I would hope that it was not your intention to remove the functionality of interoperability with Google/Yahoo/Mapquest map applications, because I will find it difficult to see why that is desirable. Also, if you can point to a standard that gives guidance on how vEvent fields are specified for approximate historical dates, then that is exactly what Commons needs, because large numbers of our images have imprecise dates within a known range of time. If it was your intention to remove interoperability with the mapping applications, then we can present our differing arguments to the community.

Regarding the number of pages being touched, my goal has been ease of authoring, so I have attempted to use it for an extended period in order to see weaknesses with real world examples. The syntax has evolved considerably during this period. I am tracking these pages with a hidden category for good reason: removal of the templates is trivial via bot if the experiment is deemed undesirable by the community. A secondary reason is that due to the nature of these navboxes, showcasing their utility is difficult without applying them to a number of pages.-J JMesserly (talk) 06:02, 25 January 2009 (UTC)[reply]

If this is an experimental template, why is not not labelled as such; and why is it not in user-space? I have already highlighted, more than once, that it is curenty emitting bogus and broken metadata from live pages; and tried to remedy that, but have been repeatedly reverted. I have no intention of devising an alternative version of this template; I offered early on to help to fix it, and asked for better documentation; both comments were ignored. As I have also made clear, above, the relevant microformats should not be emitted by this template, but by {{Information}} and related templates and will accordingly be expending my energy in that endeavour. We already have templates to emit Geo microformats, so the broken fragment of one in this template is a complete waste of time and effort; and demonstrably harmful to the project. [Brief reply, as I have to leave home now. More later, perhaps.] Andy Mabbett (talk) 12:01, 25 January 2009 (UTC)[reply]

Removal of interoperability with Google/Yahoo/Mapquest applications

I can only assume that there was a lack of understanding that removal of hcard in the recent "fix" to the template:place/doVEvent code is like putting <nowiki> at the beginning of an article. Anyone that doesn't understand what removal of hcard means can observe the effects of the "fix" by installing Operator extension, reverting {{Place/doVEvent}} to Andy's version, then previewing an article such as File:Paris Porte Saint-Denis c1840.jpg doing a Before and After side by side comparison. Yahoo and Google map buttons simply stop working with this "fix", and the same would be true not just for Operator, Google, and Yahoo but for any future browsers and applications that recognize microformats. I presumed it to be intentional removal of functionality of interoperability with Yahoo & Google, and if I was in error about that, then Andy, I apologize for interpreting doing that without discussion as vandalism.

At a technical level, if the semantics of the fragment removed is indeed "broken", then what needs to be explained is why both Google Maps and Yahoo Maps recognize it perfectly fine. Collaboration is what the wiki way is all about, but rather than choosing to refine the code, expunged functionality that delivers benefit to end users is a matter to be given more consideration and discussion. The Microformats Hcard page specifies that Place names are to be encoded with fn and org in the same element:

If the "FN" and "ORG" properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company, organization or place and SHOULD be treated as such.

That's what the code emitted does. Regardless, I very strongly agree that the Commons pages should not offer location metadata if precise {{Location}} data is present, and not only the docs reflect that, but I specifically removed geo support code prior to this incident. When the geocoding template does interoperate with Google/Yahoo/Mapquest applications via the exposed metadata, I will have a flag to suppress output of the hcard data and direct authors to set the value when {{Location}} information is available for the same location. Like I said, if a consensus of geocoding folks feels what I am doing is undesirable/harmful, I am willing to go by their judgement. As of this date, I have recieved no reply on my notice on their project page though it is now getting buried under other notes. -J JMesserly (talk) 16:03, 25 January 2009 (UTC)[reply]

The fact that Google or Yahoo! manage to make a stab at finding the location represented by an unformatted string of text does not contradict the fact that the metadata semantics you are applying to that text are bogus; as outlined above ("whose locality (as explicitly distinct from a smaller street-address or larger region) is "Rond Point, Avenue des Champs-Élysées, Paris, Île-de-France"?"). You changed the template to use fn org after the above exchange; and it is still emitting the broken Geo microformat (}") which I removed and which you have three times reverted to restore. Nonetheless, apology accepted. Andy Mabbett (talk) 20:14, 25 January 2009 (UTC)[reply]

Actually fn org was in the code one week ago, so your assumption again is mistaken. see edits for 1/18/2009 Please be more careful in your branding of my contributions to hCalendar. The best way to encode the locality information is an area of ongoing development, as is the encoding of dates, but the practicalities are not as trivial as you suggest. Please try and actually create something that does what you say. You will learn there is a lot more to this than theory. Besides, these are premature implementation details that require a full wide discussion. I'd rather have folks achieve consensus on how we want to emit these particular values from WP/Commons rather than code it multiple times. Until then, as I said, you have not demonstrated any harm caused by this functionality. It is easily reversible in the template code, so even if there were harm, it is not permanent. So really, I have a hard time understanding why you are so intent on shutting this functionality down. It works now and it has benefit to end users. -J JMesserly (talk) 22:20, 25 January 2009 (UTC)[reply]

Whatever was in the template a week ago, the class "fn" was - wrongly - used in isolation yesterday, until the edit cited above; so your claim that I am mistaken is untrue. Please be more careful in your false accusations about me. The best ways of encoding locations and dates in microformats are already known, and widely used, not least in the hundreds of templates I have modified to do so (and assisted many others to modify) on Wikipedia. I already know - and have made clear that I know, that there is more to this than theory; a fact which you seem very reluctant to accept, for some reason. I have already demonstrated harm, more than once, done by your broken implementation and emitting of bogus metadata. That you choose to ignore requests to explain or justify such behaviour does not make it correct. Where I have reversed the damage done by this template, you have repeatedly reverted me, with fallacious justification in your edit sumamries (for which comments, I acknowledge, you have since apologised). If you have any questions about tee correct implementation of microformats, I shall be happy - as I have already indicated - to answer them for you. The template most certainly does not work now, if "working" is meant to include the emission of valid, semantically correct and appropriately precise metadata. Andy Mabbett (talk) 22:46, 25 January 2009 (UTC)[reply]

Andy, your observations have been noted. I appreciate you are trying to make Commons better, and in this we are steadfastly united. Thanks for your input, and I look forward to your further contributions.-J JMesserly (talk) 23:34, 25 January 2009 (UTC)[reply]

Microformats Project

I have created Commons:Microformats Project to facilitate and coordinate the discussion and deployment of microformats on Commons. If you have an interest in microformats, please join in! Andy Mabbett (talk) 15:41, 24 January 2009 (UTC)[reply]

Comments

It's a very good template, but it has the potential to become way too large as cities and countries are added. Is there some way to narrow the scope? For example, what do general, non-decade specific categories such as "Architecture of x" have to do with (for example) the 1890s? Further, the images in the template could be overkill, since the catgories themselves consist primarily of thumbnail size images. Typically, we don't create galleries on Commons category pages. Don't mean to be critical, since a lot of work and thought obviously went into this, but the template seems massive to me -- the best templates are simple and sleek. --skeezix1000 (talk) 17:06, 14 January 2009 (UTC)[reply]

The contents of the "State/Province/Oblast" field also have the potential to become umanageable over time.--skeezix1000 (talk) 17:20, 14 January 2009 (UTC)[reply]

There is an obvious scaling issue, and the solution is technical. I make this notation for you if you are a template writer, or other writers who may read this in the future and wonder how this would work. The solution is local context, which for time was easy because I could limit scope using the #expr math function. Similar scoping can be achieved for contextually related place, thing, and people (profession) cats with string functions. The idea is that you put lists of the states of a country (or cities of a state and so on) in a special kind of page which only stores a string. The name of the page has the name of the country. You then use the #explode string function to extract all the states pass them to the helper aux templates. It might seem like there are post-expand or server load issues as you iterate over the exploded string, but actually this is not the case.

Hopefully by the time the size of the list becomes a burden, the needed extension will be accepted for use by the foundation wikis. To repeat my plug on this for other readers: It happens to already be in use on the en:wikias for 1.5 years. It appears there are some minor integration issues only standing in the way and it just needs some higher prioritization. All interested readers are encouraged to vote for bugzilla:6455

If sleek navboxes in the style of wikipedia would do the job, I'd be all for them. The difference that argues in favor of prolix navboxes on commons is the paucity of wikitext links. Few people add descriptions, and for those that do, few help you find anything else on commons. That means search won't find good images, and neither can you click links as in wikipedia articles. You are left with navigating category structure- whose limitations for lay users have been amply discussed on commons. The navbox bypasses all those canonically correct pigeonholes that media gets hidden in.

"Architecture of" etc- yes. Apparently you wrote this before you saw the developments from this morning. I left those in the same navbox, but obviously there are two. It made development simple by keeping them inside the same. Anyway, the current version has nontemporal place categories separate in Template:Place. You are watching a sketch in progress, and I forsee a lot of mutation especially having to do with things in decade cats, and triple dimension cats (eg:Category:Naval ships of Germany in the 1890s, which I have not convinced myself is a good idea yet (combinatorial explosion of cat names).

Anyway, thanks for your comments- I can see you appreciate the issues of this navbox. -J JMesserly (talk) 20:01, 14 January 2009 (UTC)[reply]

As a technical note, I implemented this using switch arrays. eg:template:place info Berlin String Functions might make this a lot more elegant, but we work with what we have, and what we have now is certainly a lot better than 2 years ago. I appreciate the server load issues, and given the choices, I prefer fast servers and getting along with #switch. -J JMesserly (talk) 17:34, 23 January 2009 (UTC)[reply]

Browser specific?

Does template this rely on browser specific features? Samulili (talk) 09:07, 25 January 2009 (UTC)[reply]

No. Although support for microformats is most advanced in Firefox, plugins are available for other browsers ("Oomph" for IE, for example) and there are on-site scripts and stand-alone websites which will also interpret them. Andy Mabbett (talk) 11:50, 25 January 2009 (UTC)[reply]

Andy is correct. {{Creator}} and {{Location}} also emit this metadata, and it is easy to overlook the significance of the growing use of microformats on Commons. To speak candidly and somewhat boldly, I expect nothing less that it is Commons' destiny to be the global source of microformat encoded knowlege. If we are to achieve that destiny, we need to make it simple for contributors to encode this metadata and check its accuracy. I expect there will be a lot of competition from the various vendors on supporting this internet standard in the next few years. Personally I mention Operator and Firefox for the reason Andy mentioned. I heard IE announced its next version will support microformats, and I think Firefox has made similar noises. -J JMesserly (talk) 16:20, 25 January 2009 (UTC)[reply]

So, if I understand thing correctly, this is, in fact, a techonology that is available to few (in Firefox with an extension, in IE with a plugin). It would seem to me that adopting this technology over another will reduce accessibility of Commons - if an alternative exists. I'm not sure that I have understood microformats, but I think I should ask, if this is not something that could be done in other ways, although maybe with some server-side scripting? Samulili (talk) 17:52, 25 January 2009 (UTC)[reply]

hcard and the other microformats are a data format specified in html, and not a technology. The web applications may or may not recognize the data, and will do different things with it- eg. some history blog might have a toobar widget that allows the user to collect links to interesting historical information they find on commons and elsewhere on the net. As for existing microformat aware net applications, the map, address book and calendar applications each do their own thing on the data that Commons could never anticipate. It is exposed in microformat tags within Commons and Wikipedia pages. Within the data this template is emitting is a link url back to the Commons page. Eg: try yahoo calendar on one of the pages using this template. The first page you see, click on the event name and you get back to the originating commons image that the event microdata refers to. Search engines can also use such metadata for searching trusted sites- eg: a future Yahoo search for images in the period 1870 to 1880 from France. So contrary to your initial impression that this might reduce accessibility, rather it would increase accessibility of Commons.

So I guess I am not understanding the problem server side scripts would address. Is it the number of expensive calls this particular template uses? If so, that is entirely unrelated to microformats. Most of that processing expense has to do with scanning for categories so that a dynamic navigation box can be constructed given a place and decade.

I suppose that a timeline gagdget might be implemented using this data, but the pages would still have to emit the data somehow, so it is probably best that they access the data using a standard like microformats, and that it be emitted from templates since the microformats standard and applications using them are rapidly evolving. Such a server side application would have inherent benefits if run on Commons due to efficiency of sql processing. So again, it adds accessibility to commons rather than detracts. -J JMesserly (talk) 18:33, 25 January 2009 (UTC)[reply]

No; see my references to "on-site scripts" and "stand-alone websites", above. The correct use of microformats will be invisible to anyone not using a microformat parser, but freely available to anyone, using such services as the latter. For example, if you paste the Commons URL http://commons.wikimedia.org/wiki/File:002657_7304b4b1.jpg into http://suda.co.uk/projects/microformats/geo/ you get a KML file for the location of the image, which can then be used elsewhere, such as in Google Earth; or viewed in Google maps, on any web-capable device. Sooner or later, Google (who are already shooing interest in using microformats) will cut out that intermediate stage. Andy Mabbett (talk) 19:19, 25 January 2009 (UTC)[reply]

time zones

Here are the time zones recognized:

  'GMT'  =>   0,           // Greenwich Mean
  'UTC'  =>   0,           // Universal (Coordinated)
  'WET'  =>   0,           // Western European
  'WAT'  =>  -1*3600,      // West Africa
  'AT'   =>  -2*3600,      // Azores
  'NFT'  =>  -3*3600-1800, // Newfoundland
  'AST'  =>  -4*3600,      // Atlantic Standard
  'EST'  =>  -5*3600,      // Eastern Standard
  'CST'  =>  -6*3600,      // Central Standard
  'MST'  =>  -7*3600,      // Mountain Standard
  'PST'  =>  -8*3600,      // Pacific Standard
  'YST'  =>  -9*3600,      // Yukon Standard
  'HST'  => -10*3600,      // Hawaii Standard
  'CAT'  => -10*3600,      // Central Alaska
  'AHST' => -10*3600,      // Alaska-Hawaii Standard
  'NT'   => -11*3600,      // Nome
  'IDLW' => -12*3600,      // International Date Line West
  'CET'  =>  +1*3600,      // Central European
  'MET'  =>  +1*3600,      // Middle European
  'MEWT' =>  +1*3600,      // Middle European Winter
  'SWT'  =>  +1*3600,      // Swedish Winter
  'FWT'  =>  +1*3600,      // French Winter
  'EET'  =>  +2*3600,      // Eastern Europe, USSR Zone 1
  'BT'   =>  +3*3600,      // Baghdad, USSR Zone 2
  'IT'   =>  +3*3600+1800, // Iran
  'ZP4'  =>  +4*3600,      // USSR Zone 3
  'ZP5'  =>  +5*3600,      // USSR Zone 4
  'IST'  =>  +5*3600+1800, // Indian Standard
  'ZP6'  =>  +6*3600,      // USSR Zone 5
  'SST'  =>  +7*3600,      // South Sumatra, USSR Zone 6
  'WAST' =>  +7*3600,      // West Australian Standard
  'JT'   =>  +7*3600+1800, // Java 
  'CCT'  =>  +8*3600,      // China Coast, USSR Zone 7
  'JST'  =>  +9*3600,      // Japan Standard, USSR Zone 8
  'CAST' =>  +9*3600+1800, // Central Australian Standard
  'EAST' => +10*3600,      // Eastern Australian Standard
  'GST'  => +10*3600,      // Guam Standard, USSR Zone 9
  'NZT'  => +12*3600,      // New Zealand
  'NZST' => +12*3600,      // New Zealand Standard
  'IDLE' => +12*3600       // International Date Line East

-J JMesserly (talk) 08:04, 4 February 2009 (UTC)[reply]

Adding Countries to the list

Would it be possible to add Switzerland to list of countries in the Navbox? After all there are also countries like El Salvador listed that are probably equally unimportant... Thank you for your help. sidonius (talk) 15:36, 20 October 2009 (UTC)[reply]

This kills page load speeds

Is there any cruft we can trim out of this? Any feature that we can live without? Pages using this load much slower than they should. There's also the issue of too many expensive parser function calls (two uses push it over the 500 limit, like seen on it's /doc page). The latter can cause problems if it's used on a page that already has a lot of expensive parser functions. For example, using it along side a similar template would break things. Rocket000 (talk) 19:25, 2 August 2010 (UTC)[reply]

This template is cruft. Takes over 20 seconds to load the damn template. Multichill (talk) 20:48, 2 August 2010 (UTC)[reply]

Agreed. I cleaned up some bits a while ago, probably gonna reduce some more latter. At least I now understand how hat thing works--DieBuche (talk) 21:52, 2 August 2010 (UTC)[reply]

Template bugs

This template is causing some categorization bugs. Please see the discussion at the English Wikipedia Village Pump.

There is also a problem with the "Navigating (Country)" drop-down box. See Category:Chile in the 1970s. The "About Chile" part link to a category about the United States, not Chile. Jason Quinn (talk) 23:30, 22 November 2010 (UTC)[reply]

Incorrect 21th century

Instead of 21st century the template shows 21th century. There are no word like twenty-firth. --Diwas (talk) 13:31, 20 January 2011 (UTC)[reply]

Now I notice that it doesn't display the 21st (or even the "21th") at all. Is there some way to rectify that? Infrogmation (talk) 18:06, 25 June 2011 (UTC)[reply]

Incorrect format

The 17 century is not the correct format for the ordinal-suffix. Best way today and used on wikipedia is 17th century. A correct old way are smaller letters positioned not as high as now. --Diwas (talk) 14:25, 20 January 2011 (UTC)[reply]

Template rendering at top

Shouldn't this appear at the bottom of the page? It seems inappropriate for a navigation device, that is not directly related to the categories that it serves, to take up so much screen space at the top. NYCRuss ☎ 16:36, 25 January 2012 (UTC)[reply]

Agree, but category contents follows always its description, so I don't think we can change that. Moreover, by the day that we have a full list of countries, cities, centuries and topics, the thing will probably explode. --Foroa (talk) 17:21, 25 January 2012 (UTC)[reply]

Just to be clear, are you saying that category contents always render below this template, and that this can not be changed? NYCRuss ☎ 17:45, 25 January 2012 (UTC)[reply]

candidate for deletion

dear @all, in my eyes this is not really a good template. It doesn't really refer to neighboring countries and not on time information either. I don't want to request deletion because it is used thousands of times, but whenever I see this template I replace it with a better working one (one of my recent updates Belgium in the 1150s). happy to @all, anro (talk) 22:14, 28 March 2024 (UTC)[reply]

Remove from files?

Can we remove this from the remaining 124 files: Special:Search/File: hastemplate:"places by decade"?

Current files like File:Paris Porte Saint-Denis c1840.jpg show up in searches for any of "Amsterdam · Barcelona · Berlin · Brussels · Buenos Aires · Cairo · Cape Town · Chicago · Delhi · Frankfurt am Main · Geneva · Hong Kong · Istanbul · Jerusalem · Kolkata · London · Los Angeles · Madrid · Mexico City · Moscow · Mumbai · New York City · Paris · Rome · San Francisco · Shanghai · Singapore · Stockholm · Sydney · Toronto · Washington, D.C. · Algeria · Argentina · Australia · Austria · Azerbaijan · Bangladesh · Belarus · Belgium · Bolivia · Bosnia and Herzegovina · Brazil · Bulgaria · Canada · Central America · Chile · China · Croatia · Cuba · Czech Republic · Denmark · Egypt · Finland · France · Germany · Greece · Guatemala · Hungary · India · Indonesia · Iran · Israel · Italy · Japan · Mexico · Namibia · Netherlands · Norway · Panama · Poland · Portugal · Romania · Russia · Serbia · Sierra Leone · Slovakia · Slovenia · South Africa · Spain · Sweden · Switzerland · Thailand · Turkey · Ukraine · United Kingdom · United States · Uruguay · Vietnam ·". Also, the layout doesn't seem to go with {{Information}} Enhancing999 (talk) 14:53, 13 August 2024 (UTC)[reply]