Page MenuHomePhabricator

Special:Log is offering invalid year numbers
Closed, ResolvedPublic

Description

https://en.wikipedia.org/wiki/Special:Log or any other wiki is offering strange year numbers: 0, 1, 2, -1, -2. I was not aware of Wikipedia at 2 BC.

I presume it was forgotten to add the current year, but there wouldn't be any log entries in future years to be selected. Otherwise you might add future lottery jackpot numbers as well.

Related Objects

Event Timeline

PerfektesChaos raised the priority of this task from to Needs Triage.
PerfektesChaos updated the task description. (Show Details)
PerfektesChaos subscribed.
This comment was removed by Krenair.

We could theoretically set a minimum to whatever year the earliest log entry occurred in, and a maximum (and default) at the current year.

The "year zero" for any wiki is 2001. I don't know whether it is possible to retrieve easily from the database when the Klingeon Wikipedia has been started. No log entry before first edit, at least no meaningful filtering in the year before.

There are no results beyond current year. This figure may be displayed as default, or kept empty with the same meaning.

The "year zero" for any wiki is 2001.

For any wiki that begun with phase 1/2, sure. That's not necessarily true if you imported content from an older wiki (you could theoretically have wiki data going back to 1994, although I don't know if the wiki software in development at the time had an equivalent of our logging system).

I don't know whether it is possible to retrieve easily from the database when the Klingeon Wikipedia has been started.

Not when it was started exactly - but I can still get into the old Klingon Wikipedia database and find information such as the first log entry or first revision timestamp.

Before 2001: Well, actually that doesn't matter. Even if there has been a log entry from 1999, it is still before 2001 and will be displayed by filtering "before/until" 2001.

However, it is very unlikely that any WMF or other wiki has imported log entries before 1/2/3; at that time even the older revisions were dropped (if more than 100 or so) and the database has been quite slim.

No one has a need to distinguish log entries of 1998 from 1999 since getting flooded otherwise.

And if you know the year of the first revision in the database then the 2001 default isn't required at all, might be July 4th 1776 if desired.

Hmm, I'm not sure, if 2001 is a nice default (think about third parties, e.g.). What about the actual year? That sounds like the easiest solution for me :)

No, there are two limitations of the range of generated option entries:

  • the newest year number
  • the oldest year number

Most obviously the current year seems to be the upper limitation, no one can filter entries in future years. But we were pondering over the default for the oldest year.

2001 includes any entry before. If somebody happens to have log entries of 1999 in wiki, they are displayed, too. There is only a lack to omit the 2000/2001 entries by user interface then.

2001 should be fallback in case detection of earliest edit fails for any reason. Database might be empty or in bad condition, but user interface still offers nice year numbers.

On December 31st next year might be offered, too: When UTC might be in last year, you might have had a HNY drink already. Or the other way around: There are log entries next year you cannot filter.

  • However, if the empty selection (no year chosen, no number displayed) simply means "nothing filtered", they will appear anyway.

BTW:

  • Entry list is done in local time, but filtering is done in UTC.
  • That means: I get the entries of the first hours of the month following my filter criterion, too, if I am not located around London UK.
  • Retrieval should use project time, or even user world, but the same time zone which is used to display the logged actions.
  • Then on December 31st no gap occurs.
Janbery subscribed.

On 1.35.0-wmf.5 (rMW2e20cac2fd1c) 25. 11. 2019, 18:49 looks fixed to me.