Template talk:ISOdate/Archive 1

2011-11-24 14:37:35‎ seems to be a devil's time.. Not interpreted for me

• {{ISOdate|2011-11-24 14:37:25}} → 24 November 2011, 14:37:25
• {{ISOdate|2011-11-24 14:37:25‎}} → 24 November 2011 14:37:25‎ (new)
• {{ISOdate|2011-11-24 14:37:35‎}} → 24 November 2011 14:37:35‎
• {{ISOdate|2011-11-24 14:37:34}} → 24 November 2011, 14:37:34
• {{ISOdate|2011-11-24 14:37:36}} → 24 November 2011, 14:37:36

at least currently in en and de interface. Thanks for fixing. :) Cheers --Saibo (Δ) 17:11, 24 November 2011 (UTC)

You are a mean person ;-) I looked for the source of the problem for ages unable to point the finger at any problematic portion of the code. Until I ended up with "{{#switch:2011-11-24 14:37:35‎|2011-11-24 14:37:35=equal|#default=unequal}}" which resulted in "unequal". That's impossible by the PHP implementation and made me realize that the fault is not in the code but in your string: you have some non-printable character at the end of the string. If you place the cursor behind the 35 and hit backspace, it'll remove the charachter and it will render just fine:

• {{ISOdate|2011-11-24 14:37:25}} → 24 November 2011, 14:37:25
• {{ISOdate|2011-11-24 14:37:35‎}} → 24 November 2011, 14:37:35
• {{ISOdate|2011-11-24 14:37:34}} → 24 November 2011, 14:37:34
• {{ISOdate|2011-11-24 14:37:36}} → 24 November 2011, 14:37:36

--Slomox (talk) 10:11, 25 November 2011 (UTC)

Damn.... As I said: "DEVIL"! ;-) Sorry. In other wikis I use WIkEd - but not here so I cannot see this char. Probably it went there because I had copied the time out of a page's history. I have just added a second line in my post by copying the third and just changing the 3 to a 2. Anyway: isn't there a kind of filter we could put in front of the date interpretation logic which strips all character which are not expected to prevent this hard to detect problem. Honestly, this was no proof of concept I really did not know what happened but wanted to use this template with this date/time. Cheers --Saibo (Δ) 14:08, 25 November 2011 (UTC)

I am not aware of any wiki-functions that allow to strip characters like this one. --Slomox (talk) 15:25, 25 November 2011 (UTC)

Yes, probably it isn't possible: too limited functionality. Extension:StringFunctions are not enabled here. Just some workarounds exist: en:Template:String_templates_see_also_text Cheers --Saibo (Δ) 15:45, 25 November 2011 (UTC)

This section was archived on a request by: Saibo (Δ) 15:45, 25 November 2011 (UTC)

Bugs in #time

Have bugzilla reports been made on the bugs in #time? -J JMesserly (talk) 07:10, 3 February 2009 (UTC)

They are not exactly bugs. {{#time: H:i, Y | 2008 }} being rendered as "00:00, 2008" instead of "00:00, 2008" is standard-compliant behaviour. But it's not what we want in our case. Reporting it to Bugzilla would result in "wontfix", I guess. --Slomox (talk) 16:06, 3 February 2009 (UTC)

Really? {{#time: Y | 1953 }} ⇒ 1953 is compliant? Do you know the rational why is 1953= 2009 if month is not specified but 1953= 1953 when it is EG: {{#time: Y | 1953-1 }} returns: 1953 ? -J JMesserly (talk) 18:43, 3 February 2009 (UTC)

It's not ISO compliant, I guess, but it is PHP date functions compliant, and {{#time: }} is based on PHP date functions. The behaviour is ridiculous, but it's the way the function works. You can try to file a bug, but I'm not too optimistic. --Slomox (talk) 19:55, 3 February 2009 (UTC)

OK thanks. Will you vote in support of fixing the bug if I list it? If so, we might as well mention all the uh "anomalous" behavior we are aware of. Do you have any other examples? By the way, I can't get it to recognize any form of BC or BCE or negative (ISO8601 BCE compliant) dates. Do you know of any way it will recognize BC? -J JMesserly (talk) 20:14, 3 February 2009 (UTC)

To answer my own query, the rationale for the anomalous behavior I documented above is that an attempt is first made to interpret numeric values as a time value. See below section for further details on this, other limitations of #time function, and how to use #time function more properly. -J JMesserly (talk) 17:29, 4 February 2009 (UTC)

Oh, sorry, I thought you were aware, that the function handles four digit years as hours and minutes. That's why I chose "H:i, Y" as example. --Slomox (talk) 17:53, 4 February 2009 (UTC)

Nope. My bad. I scanned the docs but did not consider the implications of the note that it tries to interpret as hours minutes first. Of course, it is reasonable to try to interpret 1941 without a colon as a time and not a year- not what I am accustomed to, but perfectly reasonable. Anyway, it is incorrect to say that it always interprets as a time- if it is an illegal time then it interprets as year. So it sometimes returns the correct year, just not reliably unless you do the procedure below or something like Sparkla's suggestions on the talk page for parserfunctions- which didn't help with my problem set. -J JMesserly (talk) 22:15, 4 February 2009 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Unexpected space in Korean

In Korean, date format should be Y년 M월 j일. But I see unexpected space between Y and "년". For example, {{ISOdate|2009-04-28|ko}} shows 2009년 4월 28일. Valid date format is 2009년 4월 28일. Please fix this problem. Thanks.--Kwj2772 (msg) 15:16, 27 April 2009 (UTC)

I changed {{Date}} so it removes unneeded whitespace. Fixed now. --Slomox (talk) 15:28, 27 April 2009 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

incorrect localization

I noticed that {{ISOdate|1999-09-01|pl}} (1 września 1999) ignores {{{2}}} parameter and uses {{int:Lang}} instead. But {{ISOdate|1999-09}} (wrzesień 1999) works just fine. --Jarekt (talk) 20:50, 10 June 2009 (UTC)

The error was in Template:I18n month-gen, which did not observe the passed language parameter. Should be fixed now. --Slomox (talk) 13:32, 11 June 2009 (UTC)

thanks --Jarekt (talk) 14:54, 11 June 2009 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Ymd template

I've created a template which does the reverse of this - {{Ymd}}. It takes a date in various formats, and converts to to ISO 8601 format, which can then be fed into this template. If it works (which it seems to), I'm going to suggest using it in the {{Information}} template, to reduce the need for bots to standardise the date format in images. – Tivedshambo (talk) 21:51, 7 July 2009 (UTC)

Dates and their correct handling are quite complex (that's the reason, why we need all these date templates). I think the bot work should still be done. Cases, where the template fails at the moment:

• {{Ymd|1954}}: 1954-06-05
• {{Ymd|1954-05}}: 1954-05-01
• {{Ymd|5-05-05}}: 2005-05-05

{{#time: }} very often fails to interpret strings in the most obvious form. --Slomox (talk) 23:47, 7 July 2009 (UTC)

{{ISOdate|{{Ymd|01/02/2003}}}} returned 1 February 2003 but in US most common date format is mm-dd-yyyy, so for US authors 01/02/2003 should mean January 2, 2003. --Jarekt (talk) 03:55, 8 July 2009 (UTC)

The enwiki template {{date|date|iso}} seems to handle most date formats ok - I'll see if it can be adapted to improve Ymd. I've asked the conversion bot's owner how it handles ambiguous dates. I'm not saying this template will handle all eventualities, but if it can deal with most of them then it will reduce amount of work required by the bot. – Tivedshambo (talk) 07:20, 8 July 2009 (UTC)

As the operator of Slobot, which has made about 500,000 date standardization edits until now, I too will answer the questions you asked Emijrp:

• Foreign dates (e.g. date=27 Janvier 2009): My bot uses a list of translations of the month names and converts other language dates too.
• Unambiguous dates in the format date=27/5/2004 or date=5/27/2004 (i.e. UK or American): These dates too are converted.
• Ambiguous dates (e.g. date=4/7/2009 - which could mean 4 July or 7 April): Ambiguous dates are _not_ converted by my bot. But I plan to expand the bot so that it can check the EXIF data for the date field and if the EXIF date matches one of the two possibilities, it will be converted. But this is not yet done or implemented.
• Unparseable dates (e.g. date=Probably some time during summer 1994): The string "Probably some time during summer 1994" just stays that way. If the date parameter said "summer 1994", my bot would standardize it to the localizable form "{{Other date|season|summer|1994}}", which renders as "Summer 1994
  date QS:P,+1994-00-00T00:00:00Z/9,P4241,Q40720564
  ".
• Also dates specifying month only - e.g. date=June 1985: These will be converted to "1985-06" which is localizable through ISOdate/Date.

--Slomox (talk) 12:21, 8 July 2009 (UTC)

So what's the general feeling here? Is this worth pursuing, or would it be easier for bots to convert all date formats rather than just complicated ones? – Tivedshambo (talk) 14:13, 8 July 2009 (UTC)

I would leave it to the bots - they are more flexible. --Jarekt (talk) 14:28, 8 July 2009 (UTC)

Fair enough. I'll still see if I can improve the template though - it may still be useful elsewhere. – Tivedshambo (talk) 16:48, 9 July 2009 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Even month error

Even months do not show up correctly when using yyyy-mm notation. See below

• January 1999
• February 1999
• March 1999
• April 1999
• May 1999
• June 1999
• July 1999
• August 1999
• September 1999
• October 1999
• November 1999
• December 1999

--Jarekt (talk) 17:13, 31 July 2009 (UTC)

It must be an error in the parser. "{{#time:m| 1999-02 }} : {{#time:m| 1999-03 }}" renders as: "02 : 03"

That's no meaningful behaviour as far as I can judge. And I'm almost sure, that it worked, when I tested the template.--Slomox (talk) 22:03, 31 July 2009 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Template broken

Currently the template is broken for full dates lower than 70-01-01:

• {{ISOdate|70-01-01}}: 1 January 0070
• {{ISOdate|69-12-31}}: 31 December 0069

It worked in former versions. I have not yet identified the edit that introduced the error. At the moment I don't have time to investigate the problem. (Perhaps tomorrow or the day after tomorrow.) So if anybody can identify and/or fix the problem, feel free to do it ;-) --Slomox (talk) 00:00, 13 August 2010 (UTC)

Should be fixed now. Was a rather big edit. I hope I introduced no new issues. The template is so esoteric it's just ridiculous. We really need build-in support for this in MediaWiki... --Slomox (talk) 20:25, 18 August 2010 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Expansion depth limit exceeded

This template may be at fault (I'm not sure) for pushing us over the expansion depth limit in certain templates. For example, {{Self-portrait with Felt Hat (1888)}} uses {{Creator:Vincent van Gogh}}, which uses {{Other date}} inside another {{other date}}, which in turn uses many {{ISOdate}} templates. This works fine on the template page itself, but when transcluded just one more time, like on File:Self portrait with Felt Hat.jpg, it breaks (uncollapse the creator template to see what I mean or expand it). We could alter those templates to avoid this, but since this is a very versatile template, it would be great if we can fix it by splitting this up somehow and optimize it. OTOH, maybe {{Other date}} can be changed instead. Rocket000 (talk) 18:50, 30 August 2010 (UTC)

Moving all the documentation of {{Self-portrait with Felt Hat (1888)}} to a separate documentation subpage may help. (I mean, I don't know if it fixes this particular problem but it does help to fix similar problems.) --Apalsola ^{t • c} 21:31, 30 August 2010 (UTC)

The documentation is <noinclude>'d so it doesn't affect the template's usage and is completely ignored when transcluding. It used to matter a few years ago and that's why people got in the practice of using /doc pages. (The page you link to says: "...the practice of using a template documentation page, which can still be useful for other reasons, is no longer needed for avoiding documentation to be counted on pages that call the template.") Anyway, I know we can do work-arounds for individual templates, but I'm hoping we can modify this template so that's not necessary. Rocket000 (talk) 23:25, 30 August 2010 (UTC)

Thanks, I stand corrected. :-) --Apalsola ^{t • c} 09:27, 31 August 2010 (UTC)

I didn't know that particular limit so far. I guess the main problem is not with dates in correct ISO format (those need the most depthy branches of the template, but they usually run these branches only once). The problem seems to be with strings that cannot be processed by ISOdate (because they were already processed by a more depthy instance of ISOdate). These strings run through line 5 of the template in a depth of +4. I prepared a new version of ISOdate at User:Slomox/test12. It does all the testing with a single ifexpr and should thus process unprocessable strings with adding just +1 to depth. That should be enough to rescue us in cases like File:Self portrait with Felt Hat.jpg.

If you agree with me that this is the source of the problem and if you also agree that my proposed fix works then feel free to apply the fix to ISOdate. I don't want to do it myself without a second pair of eyes looking at it, because stuff is getting complex with these esoteric templates. I agree with Rocket000 that we need better built-in support for this stuff in Mediawiki. --Slomox (talk) 17:52, 31 August 2010 (UTC)

If you mean [1], that seems to be 3 levels: #ifexpr #iferror #expr. I tried it and it does not seem to help. Perhaps we should avoid nesting of Template:Other date as in {{other date|-|{{other date|circa|1880}}|1890-07}}}}. In seems wasteful in terms of expansion depth to investigate whether a parameter is a date that has to be transformed, or that it should be treated as plain text, in cases where this is known already, like after adding "circa". We could make different versions of the template depending on which date parameters are plain text, or add parameters to specify that. Either way it may also help if it can be avoided that the levels involved in determining the language in Template:LangSwitch are counted twice.--Patrick (talk) 15:15, 7 September 2010 (UTC)

Hm, after some testing my solution seems to fail even earlier than the current solution. Seems that expansion depth limit is not calculated in the way I thought it is... What does expansion depth limit actually count? --Slomox (talk) 16:12, 7 September 2010 (UTC)

I assumed that each function starting with {{# increases the counter and the counter is decreased when the function reaches its closing tag }}. Is it that the counter is only decreased when the end tag of the parent function is reached? Otherwise I don't get the problem... --Slomox (talk) 16:48, 7 September 2010 (UTC)

Expansion depth limit is a bitch... I really don't get it. Please have a look at User:Slomox/test13 and its source code. The first statement has 37 nested ifs and doesn't fail (it fails with 38). For me that proves that the maximum depth of "{{User:Slomox/test10|~|{{User:Slomox/test10|~|{{User:Slomox/test10|~|1800}}}}}}" is 3. So the second statement " {{User:Slomox/test10|~|{{User:Slomox/test10|~|{{User:Slomox/test10|~|{{User:Slomox/test10|~|1800}}}}}}}}" should have a depth of 4. But it fails... That doesn't make any sense... --Slomox (talk) 17:10, 7 September 2010 (UTC)

It seems that a repetition of template calls is more suitable for testing. This may have to do with the fact that with #if the condition on the page itself is evaluated and then the then- or else-part is expanded, but with a template, the template content determines which parameters are expanded (the ones that are used). I am experimenting with Template:Expansion depth test and m:Template:Edt.--Patrick (talk) 07:46, 8 September 2010 (UTC)

Gradually I begin to get a better understanding of expansion depth limit. I created a new version of ISOdate at User:Slomox/test12. In my test it decreased the depth count by 5. It facilitates a switch statement to make some of the nested functions serial. --Slomox (talk) 12:48, 8 September 2010 (UTC)

I created Template:Circa and Template:From until that fixes the problem by bypassing Template:ISOdate and directly calling Template:Date. This could be done for the other functions of Template:Other date too. For the user the call has become even shorter, e.g. Workperiod = {{from until|{{circa|1880}}|||1890|7}}.--Patrick (talk) 09:53, 14 September 2010 (UTC)

I edited ISOdate and File:Self portrait with Felt Hat.jpg works again. I don't think it's a good idea to split {{Other date}} up. We should keep together the functionality in one place.

File:Self portrait with Felt Hat.jpg is an extreme example of template nesting and I guess there aren't many pages that need even deeper nesting. So we should be fine. --Slomox (talk) 12:07, 14 September 2010 (UTC)

Please, no more date templates. It just adds to the confusion if we have dozen ways to accomplish the same task, and it takes time to clean up. Can we delete those 2 ? --Jarekt (talk) 13:01, 14 September 2010 (UTC)

I am pleased with the improvement of ISOdate. Nevertheless I oppose deletion of the new templates, because the expansion depth and other counts are lower, so they can be needed. Also, it seems dubious, if year, month and day are available as separate data items, to lump them together and then apply a complicated procedure to separate them again.--Patrick (talk) 14:12, 14 September 2010 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Orthographic error in name of German month

{{other date|by|1917-05-02}} results in “spätestens 2. May 1917”. That should be Mai, not May. --Rosenzweig δ 22:21, 25 July 2011 (UTC)

I will look into it. --Jarekt (talk) 01:38, 26 July 2011 (UTC)

Should be fixed now. For the reference the issue was that space in "| {{{2|}}}" was producing parameters like " de" which were passed to {{Date}}. I recently simplified code of {{Date}} so parameters like " de" were passed to {{I18n month}}, which could not recognize it as "de". --Jarekt (talk) 04:08, 26 July 2011 (UTC)

I had feared other templates might be involved :-) Thank you, it worked. Regards --Rosenzweig δ 11:01, 26 July 2011 (UTC)

This section was archived on a request by: whym (talk) 12:38, 3 November 2013 (UTC)

Handling BCE and other unusual dates more robustly.

These comments have to do with how I will be doing dates for microformat output. I won't be mucking with ISOdate, but include the notes here since you (slomox) appear to be confronting similar issues. I haven't gotten around to upgrading the current template, but when I have something ready, I'll drop a line.

As documented, #time works on years from 100 to 9999. My plan of record is to upshift all dates into a high year range, then downshift them for display. EG: if the user wants 40 BC, BC might be carried in an optional parameter, and internally, the 40 get converted to 3040, expressed in a uniform ISO8601 (c #time parameter) format. When we go to display, we extract the year, subtract the 3000 and indicate the BC with negative as is canonical for ISO8601. For human readers, we use bce or whatever is proper for local language. mw:Help:Extension:ParserFunctions explains some of the weird behavior that we were assuming were bugs. PHP's strtotime() function first attempts to interpret a numeric value as a Hours and minutes. 1956 is recognized as 19:56, but since 1960 is an invalid time, it interprets as a year. Besides addressing the date range limitations (as of the time of this writing) of php 5.0, the approach addresses the limitations of the "interpret as time first" behavior.

The approach I describe will correctly handle dates from 1-7999 BC, and 1-7999 AD, expressed in free text that #time will eat. Users will however be required to express BCE/ CE (BC/AD) in a separate parameter. I don't see a way around that at this point. -J JMesserly (talk) 17:18, 4 February 2009 (UTC)

I am not sure, what exact problem you want to approach. What code do you want to add to which template to achieve exactly what? --Slomox (talk) 17:53, 4 February 2009 (UTC)

• goals: Dates from 7999BC to 7999AD. Year only declarations that are not misinterpreted.
• Note that I am not specifically suggesting you do anything differently with the date templates you have been authoring, as I don't understand what the scope of application is. Most likely the first implementation of the approach I sketched above will be on en:wikipedia. I'll give a pointer when it is running. The purpose of my note was purely technical- to let you know what I discovered about strtotime(). It may or may not have utility for your work with dates. -J JMesserly (talk) 18:56, 4 February 2009 (UTC)

en:Template:Start-date is fairly stable now. If you are familiar with the requirements for encoding of event end timestamps, you will see that it properly does the date calculation, as described in here under case2:lamian war example (scan down to "case 2" for full details). -J JMesserly (talk) 18:11, 8 February 2009 (UTC)

Please give examples

For those not familiar with specific ISO standards please give an example (like, 2009-02-29), and link to w:ISO 8601 --Jarekt (talk) 01:56, 9 February 2009 (UTC)

The documentation is not protected. I have added it. --Slomox (talk) 03:35, 9 February 2009 (UTC)

Thanks for the pointer (I might need it in the future) and the changes. --Jarekt (talk) 04:51, 9 February 2009 (UTC)

This section was archived on a request by: whym (talk) 03:58, 9 November 2013 (UTC)

Should template be renamed?

ISO 8601 contains two pertinent restrictions.

The first restriction is that dates in the ISO 8601 format must be in the Gregorian calendar (or the proleptic Gregorian calendar, which is the extrapolation of that calendar to the time period before it was created in 1582). So long as the output of the template is not in the ISO 8601 format, this only matters (1) as a documentation issue, and (2) a problem with the name of the template. The documentation explicitly states the input is ISO 8601, it must not be used for non-Gregorian dates. This is easy to fix by rewriting the documentation. The name of the template implies that it uses ISO 8601, and this is more difficult to fix. I suppose we could do a redirect.

The second restriction is that ISO 8601 requres that dates in that fomat be confined to the years 1583 through 9999 unless an agreement is reached amongst those exchanging data. I suppose that we can expect those who use the template to read the documentation, and if they use it anyway after reading the documentation, they agree. Again, this is provided that the output is not in the YYYY-MM-DD format. --Jc3s5h (talk) 22:14, 22 June 2009 (UTC)

There's absolutely no problem with this template. Your concerns are exegetic and have few relevance to the template, cause the template is a pragmatic solution to a practical problem and not a place for standards legalese finickiness. --Slomox (talk) 23:07, 22 June 2009 (UTC)

It is disrespectful to invoke the name of a standards organization and the name of a specific standard when one does not intend to follow the standard. If which calendar a standard uses is so important, I wonder why the ISO bothered to mention that the Gregorian calendar must be used? --Jc3s5h (talk) 01:31, 23 June 2009 (UTC)

ISO 8601 is a standard that tells you how to write down dates so others can use them without the danger of misinterpreting them (which is most important if the one writing down the date and the one reading the date are from different cultures with differing "plain text" date formats). And that's what the templates are doing. They are storing dates in a uniform format on a multilingual (multicultural) project. The dates in the source text of the pages are all Gregorian. But dates may be rendered in different calendars. Which is completely compliant with the standard.

If you believe, that the template is not standard-compliant, then please be explicit and tell the problem. What do you want to be changed and why? --Slomox (talk) 02:20, 23 June 2009 (UTC)

Slomox wrote "The dates in the source text of the pages are all Gregorian." I'm not so sure about that. Certainly any and all files would have been placed onto the Wikimedia servers long after the adoption of the Gregorian calendar. But the files could be scans of old documents, and the description of those documents might indicate when they were originally published or signed, and those old dates might be in pre-Gregorian calendars. For example, the description for the file Magna Carta.jpg might be updated some day to indicate the exact date of the manuscript.

Perhaps the template is only intended to be used with system-generated timestamps, and ought not to be used in descriptions. If so, the documentation should be modified accordingly. --Jc3s5h (talk) 03:32, 23 June 2009 (UTC)

It's meant to be used in descriptions and users should note down the date in the Gregorian calendar. If they don't: Well, that's a general problem of a wiki, you can't secure that everybody follows the guidelines. But even if dates are written down as Julian dates, they a) can be fixed at the page level (but not at the template level), and b) that will hardly do any harm (an error of 14 or less days in the dating of the Magna Charta will not do any real damage). And we shouldn't forget, that all our content is created by humans. Most likely there a tens of thousands of dates that were noted down incorrectly in the first place (typing errors, people just erring about today's date, people completely making up dates, people copying dates from dubious sources etc. pp.). From a pragmatical point of view Julian dates are a marginal problem. --Slomox (talk) 10:57, 23 June 2009 (UTC)

 Comment According to w:ISO 8601#Calendar dates: [YYYY] indicates a four-digit year, 0000 through 9999. That is the format implemented here. --Jarekt (talk) 03:13, 23 June 2009 (UTC)

This section was archived on a request by: whym (talk) 03:58, 9 November 2013 (UTC)

Additional comments in the parameter

There are often additional coments such as (UTC), ({{according to EXIF data}}), (according to EXIF data), ({{original upload date}}) and (original upload date) in the date field of {{Information}} template. At the moment, {{ISOdate}} does not render dates in such cases. Is it possible to modify {{ISOdate}} so that it would always render its parameter provided it begins with a valid ISO 8601 date? Of course it is always possible to use {{Date}} but it would a lot easier if ISOdate could handle these cases, too. BR, --Apalsola ^{t • c} 12:00, 29 August 2010 (UTC) -- (edit) Apalsola ^{t • c} 12:09, 29 August 2010 (UTC)

It would be possible to include them. But that would mean one big switch statement where every single possible string will be included as a different case. That's the technical answer to your question. The more relevant answer is, that these types of info just do not belong in the date parameter. The original upload date does never belong in the date parameter, but only in the original version history which should be a separate paragraph. If (UTC) appears in a date convert it to a valid ISO 8601 date. The only thing that seems relevant is ({{according to EXIF data}}). But this should rather be included in the form |date={{according to EXIF data|2010-08-29}} than |date=2010-08-29 ({{according to EXIF data}}). That's the much more flexible format. --Slomox (talk) 12:46, 29 August 2010 (UTC)

Well, still some tools (such as the "Add {{Information}}" link in the left column, and Move-to-commons assistant) add "(according to EXIF data)" and "(original upload date)" texts into the date parameter, so even if they ideally do not belong in the date parameter, in practice they do.

That being said, it is a good idea to modify {{According to EXIF data}} and {{Original upload date}}) to also accept the date as a parameter. I have created both the templates, so I'll look into it. But even if we modify the templates that does not change the present situation: there are thousands of description pages with these texts in the date parameter and that is why I think {{ISOdate}} should handle them.

About converting a date with "(UTC)", at the moment (as far as I know) that is not possible if we want to retain all the information. ISOdate seems not to render (valid) timezone notations correctly:

• {{ISOdate|2010-08-29 16:45:50Z}} renders "29 August 2010, 16:45:50" while it should render (in English) something like "29 August 2010, 16:45:50 (UTC)"
• {{ISOdate|2010-08-29 13:45:50-03:00}} renders "29 August 2010 13:45:50-03:00" while it should render (in English) something like "29 August 2010, 13:45:50 (−03:00)"

And, technically valid ISO 8601 format would be e.g. "2010-08-29T16:45:50Z" (with a "T" between date and time), but I don't think we should change that since the present format is widely used and much more human-readable. BR, --Apalsola ^{t • c} 16:50, 29 August 2010 (UTC)

{{According to EXIF data}} and {{Original upload date}} now accept date as a parameter. --Apalsola ^{t • c} 17:16, 29 August 2010 (UTC)

Support for dates with a "T" instead of a " " between date and time is no big problem. It's just some additional cases for the switch.

Support for proper handling of "Z" too is no big problem. We just need to alter {{Time}} a bit. Handling timezones with an offset like "-03:00" is a bit harder. It needs masses of extra cases for the switch.

Support for original upload date and EXIF date won't work at all. Above I said it just needs a new switch with all the strings. But I forgot that the strings won't be processable by {{#time: }}. While {{#time:d m Y|2009-08-29}} will render as 29 08 2009, {{#time:d m Y|2009-08-29 (original upload date)}} will render as . There's no way how the current renderer could separate the date from the rest of the string (well there are two possible solutions I can think of, but both would lead to an immediate server outage when applied in a massively used template like ISOdate...). --Slomox (talk) 21:04, 29 August 2010 (UTC)

OK, I don't want to be the one causing Wikimedia server outage, so let's forget "according to EXIF data" etc. :-) But if it would be possible to modify the template to render timezones (or at least "Z"), that would be nice. --Apalsola ^{t • c} 08:05, 30 August 2010 (UTC)

If they would just turn on those damn StringFunctions for us... Rocket000 (talk) 23:35, 30 August 2010 (UTC)

This section was archived on a request by: whym (talk) 03:58, 9 November 2013 (UTC)

Problems with dates in incorect format

Dates in incorrect format were displayed "as is" in the (distant?) past. Now only errot message shows up see for example File:Giuspepe salviati, presentazioine di maria al tempio.jpg. There date "1548-50", which should have been {{other date|-|1548|1550}} showed up as "Unknown date Expression error: Unexpected < operator". I was expecting to see the original "1548-50". --Jarekt (talk) 13:48, 11 March 2011 (UTC)

The template does display "as is" when the given value is no ISO date. But in this case the template misinterpreted the value as "YYYY-MM" which obviously is not correct. I applied a fix to the template to catch this. Test: 1548. Works. (I hope I introduced no new unwanted side effects. If only Mediawiki natively supported multilingual date formatting we could trash this esoteric heap of nightmare code.) --Slomox (talk) 19:07, 11 March 2011 (UTC)

This section was archived on a request by: whym (talk) 03:58, 9 November 2013 (UTC)

Problem with time specification

These are all valid ISO date & time specifications, yet some of them aren't accepted by the template:

• 18 November 2011
• 18 November 2011, 11:11
• 18 November 2011, 11:11
• 18 November 2011 11:11+01
• 2011-11-18T11:11+01
• 18 November 2011 10:11Z
• 2011-11-18T10:11Z
• 18 November 2011, 11:11:11
• 18 November 2011, 11:11:11
• 18 November 2011 11:11:11+01
• 2011-11-18T11:11:11+01
• 18 November 2011, 10:11:11
• 18 November 2011, 10:11:11

In particular, I'm having trouble specifying a time zone without specifying seconds. This is often necessary as I sometimes find incomplete dates with time zone but without seconds. Besides, the time zone should probably either be displayed as "10:11:11 (UTC)" or be converted to the local time zone (11:11:11 in my case). --Stefan4 (talk) 10:17, 18 November 2011 (UTC)

This template is not supposed to cover anything valid under ISO. It's already extremely complex and costy to cover the cases covered so far and covering these extra cases would add another chunk of complexity. The template is only supposed to provide at least one input method for every use case. If you stumble over unsupported cases, please change them to a supported format. --Slomox (talk) 15:20, 18 November 2011 (UTC)

This section was archived on a request by: whym (talk) 03:58, 9 November 2013 (UTC)

Problem with hidden formatting

This template seems to output more than the just what is displayed. I tried

{{ISOdate|f=Y|1991-10-12}}

on Special:ExpandTemplates. It shows

1991<span style="display:none">(<span class="dtstart">1991</span>)</span>

rather than

1991

That means that

{{#ifexist:Category:Ships built in {{ISOdate|f=Y|1991-10-12}} |[[:Category:Ships built in {{ISOdate|f=Y|1991-10-12}} | {{ISOdate|f=Y|1991-10-12}} ]] |{{ISOdate|1991-10-12}} }}

wont work as expected. Can we remove the formatting or make it optional? --  Docu  at 21:27, 5 February 2012 (UTC)

{{ISOdate}} is very complicated, and rather hard to read or modify. Yes there is a f=Y option but nobody uses it ( see uses of tag template:ISOdate_with_f). We should probably remove that option to simplify the code and may be try to take better advantage of new capabilities of {{#time:}} function. In the past I had some similar problems and I wrote {{ISOyear}} which is used by {{Creator}}. --Jarekt (talk) 03:20, 6 February 2012 (UTC)

It seems that the problem comes from formatting added in Template:Date.

{{ISOyear}} should probably work for me, so no need to change it. --  Docu  at 07:18, 6 February 2012 (UTC)

This section was archived on a request by: whym (talk) 03:58, 9 November 2013 (UTC)