User talk:R2

From RogueBasin
Revision as of 05:58, 24 July 2008 by Kiefer (Talk | contribs)

Jump to: navigation, search

(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 --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)
OK, I will wait until the discussion ends, and change the format to "2008 Dec 03" if there is no new input. --R2 10:39, 22 July 2008 (CEST)
I don't see anything at that has anything to do with how to standardize dates. Also, it doesn't appear that (YYYY MM DD) was what was always used, as the change on the POWDER page ( uses (YYYY DD MM). For readability, using text for the month is really needed, at least if this site is meant to be more international, as opposed to regional. Kiefer 06:08, 22 July 2008 (CEST)
Sorry for breaking POWDER date. This link was only a quick explanation. A table which shows release dates for many roguelikes looks better when all the dates follow the same format, and is also more reasonable to implement when they follow a standard. I used YYYY MM DD because it's the most logical for me and because it does not need any further work. --R2 10:39, 22 July 2008 (CEST)
I do not expect impulsive decisions to be well-documented. The idea was to reduce date ordering to string-compare ordering (which is tangentially mentioned), but at the time no consideration was documented of the agonizingly obvious idea of a date format canonicalizer in the abstractor. Such a canonicalizer also would allow extending the abstractor application to more than just Roguebasin. -- Bessarion 8:03 22 July 2008 (CDT)
I believe that standardizing dates on Roguebasin is a better approach than making the abstractor understand all the date formats possible. In our case, it is just easier to eliminate the special formats (by editting) than to recognize them aumatically. Both Roguebasin and abstractor are cleaner that way, and also it makes the job simpler for anyone in the future who wants to use the data for some purpose. Having non-standardized data is like carrying a separate charger for each of your 10 electronic devices, and having a standard is like have one charger working for all of them. --R2 17:19, 22 July 2008 (CEST)
Pardon my ignorance, but is the wiki being implemented into some other project where those dates are going to be grabbed? (Once again, the lack of a Community Portal page and Help section for the wiki leaves me ignorant about this, if this is the case.) Kiefer 19:17, 22 July 2008 (CEST)
While there is an informal relation between RogueTemple and RogueBasin (e.g., the article backup feature), the formal administrator of this Wiki being AWOL makes tracing such things difficult. -- Bessarion 13:08 22 July 2008 (CDT)
We shall just have to disagree then; I'm not the one maintaining that abstractor. I have written such an omni-date converter in Perl (needed it for some log translation for one of my clients), so it's [sarcasm]trivial[/sarcasm] to write one (I would expect under two hours total time including design and testing in anything higher than assembly language, maybe about an hour in Perl). -- Bessarion 13:08 22 July 2008 (CDT)
Okay, so what I get from this discussion is that the dates aren't used anywhere else, but if they are to be in the future, they should be uniform. For programmers, that is best done as (YYYY/MM/DD), but for actual visitors to the Roguebasin wiki, (Month DD, YYYY) or (Mon. DD, YYYY) is more readable and understandable. I'm all for a wiki being implemented in other applications/sites/whatever, but I always think of a wiki as primarily a resource for a human being, and human being "scan" things differently and can read things incorrectly. I think that's shown in the POWDER date being messed up. Sometimes things have to be done in manner that benefits the general audience, rather than the needs of programmers. oh, I know that's going to go over well with this audience, he says to himself.  :-)
So, who's the head admin here, anyway? 5 admins, and User:Slash appears to be the only one that has had a serious presence here in 2008. Kiefer 05:58, 24 July 2008 (CEST)
Personal tools