Difference between revisions of "User talk:R2"

From RogueBasin
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)