Difference between revisions of "User talk:R2"
Jump to navigation
Jump to search
(/me support's Bessarion's text-month notion as a good compromise.) |
m |
||
Line 15: | Line 15: | ||
::: [[User:Bessarion|Bessarion]]'s suggestion to standardize with textual months in full is the most human readable and the simplest. I for one would be happy with it. To achieve machine readability, a standard must be used. But it doesn't matter which one. So lets have a standard so that [[User:R2|R2]] gets what they want. And lets make it unambiguous for humans and easy to read like [[User:Bessarion|Bessarion]] wants. Everybody wins. [[User:Duerig|Duerig]] 01:59, 22 July 2008 (CEST) | ::: [[User:Bessarion|Bessarion]]'s suggestion to standardize with textual months in full is the most human readable and the simplest. I for one would be happy with it. To achieve machine readability, a standard must be used. But it doesn't matter which one. So lets have a standard so that [[User:R2|R2]] gets what they want. And lets make it unambiguous for humans and easy to read like [[User:Bessarion|Bessarion]] wants. Everybody wins. [[User:Duerig|Duerig]] 01:59, 22 July 2008 (CEST) | ||
:::: Oh, it doesn't have to be in full -- C gets by perfectly well with three-character abbreviations for asctime. (IMO, the date standardizer for the abstractor application should handle both abbreviations and full names). I do prefer something where a legitimate transposition oversight doesn't change the meaning. (I use a YYYYMMDD file part myself on files not meant for public consumption to get the lexical sorting to line up with the date sorting, but that doesn't mean I think such unintuitive constructs belong in prose. I certainly wouldn't expect a non-programmer to have a clue what 2008/12/3 was supposed to mean. 2008 Dec 3 merely looks grammatically weird, but is readable.) -- [[User:Bessarion|Bessarion]] 19:36 21 July 2008 (CDT) |
Revision as of 00:36, 22 July 2008
(standardization of dates)
Whoa, what happened here. Was this site-wide change discussed anywhere? Kiefer 07:14, 21 July 2008 (CEST)
- It wasn't discussed on this wiki (so I doubt that the discussion, even if it exists, "counts"). Furthermore, it's not a uniform readability improvement. -- Bessarion 8:18 21 July 2008 (CDT)
- The reasons for standardization are at http://www.roguetemple.com/forums/index.php?topic=62 --R2 19:53, 21 July 2008 (CEST)
- That doesn't count, unless there's some undocumented management integration between the two sites. Fixing that application (a function that takes a gloppy date, and returns a standard-formed date if possible) is the correct approach. If I was to propose any (unnecessary) standardization, I would suggest four-digit years, and months as text. That way, the difference between U.S. dates and EU dates doesn't cause confusion.
- As it is, anyone from the EU who doesn't know the standardization convention is going to think the correct format for Dec 3 2008 is 2008/3/12, which breaks your abstractor application without any chance of recovery.
- I'm going to make up my mind on whether to revert this spam for Zaiband and YADS later, once the emotional reasoning no longer is in the way. -- Bessarion 17:54 21 July 2008 (CDT)
- The standard I used (YYYY MM DD) is an ISO standard (ISO-8601) for international date format, a UE standard (EN 28601), and also is the most logical format (as the usual big endian sorting works correctly on it). (The US date format is as far as I know MM/DD/YYYY and cannot be confused because of the 4-digit year which is immediately recognized. DD/MM/YYYY also should not be confused for the same reason. YYYY/DD/MM potentially could be confused, but I think it is not used anywhere as a date standard.) You are right that displaying months as text would be also a good option, and also would eliminate any risk of confusion, and would be more readable for some. But I suggest to make the template make clear that "YYYY/MM/DD" is the format to use. --R2
- Bessarion's suggestion to standardize with textual months in full is the most human readable and the simplest. I for one would be happy with it. To achieve machine readability, a standard must be used. But it doesn't matter which one. So lets have a standard so that R2 gets what they want. And lets make it unambiguous for humans and easy to read like Bessarion wants. Everybody wins. Duerig 01:59, 22 July 2008 (CEST)
- Oh, it doesn't have to be in full -- C gets by perfectly well with three-character abbreviations for asctime. (IMO, the date standardizer for the abstractor application should handle both abbreviations and full names). I do prefer something where a legitimate transposition oversight doesn't change the meaning. (I use a YYYYMMDD file part myself on files not meant for public consumption to get the lexical sorting to line up with the date sorting, but that doesn't mean I think such unintuitive constructs belong in prose. I certainly wouldn't expect a non-programmer to have a clue what 2008/12/3 was supposed to mean. 2008 Dec 3 merely looks grammatically weird, but is readable.) -- Bessarion 19:36 21 July 2008 (CDT)