Last modified: 2009-05-20 19:52:54 UTC
In Preferences one is offered the choices of 16:12, January 15, 2001 16:12, 15 January 2001 16:12, 2001 January 15 2001-01-15T16:12:34 Which are all apparently from $epoch = '20010115161234'; # Wikipedia day of Preferences.php. I would like to propose that you just use the current date and time, instead of Wikipedia day. It wouldn't hurt anybody, and it would be a big help for users of bug 18849 type calendars (Taiwan, Japan, N. Korea), where one could see at a glance the year is indeed what one expects, instead of having to calculate if it is indeed the right match for way back in 2001. As for "what current time", well, I suppose give the best estimate of the user's local time based on what he has told us so far.
Just use the site default; it's not going to kill people if it's a few hours out, it's for formatting examples, not accurate timekeeping. I agree that there's no need to keep referring to a date now over eight years past, though.
Yes, I'm most concerned that at least the year shown is the current year. (It only follows that the rest of the date components should be current too, else it will 'even look more broken'.) (By the way, if we could get this thing out of 2001 and back ticking again, perhaps we could avoid repeating one of Server time: 12:19 Local time: 20:19 by combining it with the choice list above it, but that's no big deal.) Anyways, those two fellows should be shown in full date month year format, (else who knows, maybe the machine really is stuck in 2001!) It would look more uniform with the rest, and when setting any computer's time things, one always wants to be sure we're not talking about right time, but one day off, especially near any International Date Lines, etc. (I would submit a patch but time stuff is not my area of expertise.) Allow me to bring up another point I'm sure you all will agree with. Let's look again at this Preference, Date format No preference 16:12, January 15, 2001 16:12, 15 January 2001 16:12, 2001 January 15 2001-01-15T16:12:34 'Well, what does the "No preference" style date look like?' the user says, banging his head against the wall. In fact it is shown right there on the first page of the Preferences, but still, please display it again here also too, next to the words 'No preference'. (Which by the way is a terrible translation for 'datedefault' => 'No preference', just use 'default' => 'default', but alas, in e.g., MessagesZh* the former is slightly better than the latter...)
(In reply to comment #2) > 'Well, what does the "No preference" style date look like?' the user > says, banging his head against the wall. It may be the next choice shown, some other choice shown, or none of the below. So please reveal what it looks like here, even if on the previous page.
(In reply to comment #3) > (In reply to comment #2) > > 'Well, what does the "No preference" style date look like?' the user > > says, banging his head against the wall. > It may be the next choice shown, some other choice shown, or none of the below. > So please reveal what it looks like here, even if on the previous page. > AFAIK, setting no date preferences leaves the date formatting in the article unchanged. Suppose you're viewing an article with the following text: [[January 15]], [[2001]] is Wikipedia day, as is [[15 January]] [[2001]]. With your date preference set to "No preference", this'll show as-is, with the date preference set to the one below that it'll show as: January 15, 2001 is Wikipedia day, as is January 15, 2001. i.e. all linked dates are autoformatted according to your preference.
OK, I notice that when I change my time formatting preference (to the ugly last choice in the list), it changes what is shown further up there in preferences: Registration time: 2006-09-24T18:09:47 It also changes the dates I see in RecentChanges: Show new changes starting from 2009-05-20T23:28:09 So that is what I want you to show the user who is banging his head against the wall. Gotta go. See you all next week.
Maybe a dupe (when it is, you can tag it): bug 17947
*** This bug has been marked as a duplicate of bug 17947 ***
