They're not imported revisions are they? Well, the ones that aren't unix epoch that is

@Neil_P._Quinn_WMF: Could you answer the last question?

Andre, thanks for the reminder.

@Reedy, good point. It looks like almost all of these are imported revisions, so it was probably misuse of the import tool. I imagine there's no good way to fix it, then?

SELECT COUNT(*)
FROM revision
WHERE rev_timestamp < "2003";
---
COUNT(*)
11277

SELECT COUNT(*)
FROM revision 
INNER JOIN page
ON rev_page = page_id
INNER JOIN logging
ON log_title = page_title
WHERE 
	log_type = "import" AND
	rev_timestamp < "2003";
---
COUNT(*)
11156

If you can find out what it's supposed to be, and then provide a revision_id/timestamp pair, we could import and update them

The difficult part will be working out what they are supposed to be, I guess

Ah, interesting. I'll keep this on my to-do list, then, and if I ever get some time, I'll see if I can figure it out.

I think it was because I did not include the timestamp information when I was importing the text. The import function is to import text from other wikis, but I used it to add text using manually created xml files. I sincerely express apologize to every Wikisource user, and to the Wikimedia Foundation. I apologize for the mess I've made, and the trouble it has brought.

Perhaps one way to deal with them is to delete these revisions? These pages were created when I (both wmrwiki and JerryofWong) imported them.

@Wmrwiki, don't worry too much about it! It hasn't been a problem for me; I just happened to notice the dates when I was doing some analysis and was curious to see what had caused them :)

Did you do all the imports at roughly the same time? If so, Reedy says it would be pretty easy to update the revisions to have that timestamp.

I thnk they were imported in several months, if not years.

@Shizhao: Why did you add All-and-every-Wikisource (looking at the project desc) and MediaWiki-Core-Snapshots (looking at T123313#2232273) here?

Having revisions older than the wiki is expected. The bug is having fake revision timestamps.

In T123313#2903638, @Aklapper wrote:

@Shizhao: Why did you add All-and-every-Wikisource (looking at the project desc) and MediaWiki-Core-Snapshots (looking at T123313#2232273) here?

This problem is because user who import content with wrong timestamp into wikisource. (I remember that...)

yes! just T123313#2232273

In T123313#2904454, @Shizhao wrote:

This problem is because user who import content with wrong timestamp into wikisource. (I remember that...)

That did not answer my question, hence removing random tags. Please do not add tags before reading and understanding the project descriptions. Thanks!

In T123313#2904565, @Aklapper wrote:

In T123313#2904454, @Shizhao wrote:

This problem is because user who import content with wrong timestamp into wikisource. (I remember that...)

That did not answer my question, hence removing random tags. Please do not add tags before reading and understanding the project descriptions. Thanks!

The second tag that you removed is not really random, this affects zhwikisource, which is also one of zh.* projects, maybe you should remove All-and-every-Wikisource because it's just randomly added.

In T123313#2904565, @Aklapper wrote:

In T123313#2904454, @Shizhao wrote:

This problem is because user who import content with wrong timestamp into wikisource. (I remember that...)

That did not answer my question, hence removing random tags. Please do not add tags before reading and understanding the project descriptions. Thanks!

To solve this problem need to start from two aspects:

1. How to solve the current timestamps error,
2. How to prevent the same problem again in the future

For 2, I think we should start from Export and Import:

• Suggest and encourage wiki sites to use "Import from another wiki" instead of "Upload XML data", make sure that the imported content timestamp can't be modified
• Add a new verification method. When importing content, compare the timestamp of the imported content with the first edit (such as rev 1) timestamp of the content source wiki

@Aklapper: so, I think this is a MediaWiki-Core-Snapshots

@Shizhao:

For 2, I think we should start from Export and Import:

• Suggest and encourage wiki sites to use "Import from another wiki" instead of "Upload XML data", make sure that the imported content timestamp can't be modified

Strongly oppose, it makes the New Wiki Importers' (e.g. @MF-Warburg ) work more and more hard.

• Add a new verification method. When importing content, compare the timestamp of the imported content with the first edit (such as rev 1) timestamp of the content source wiki

Feasibility investigation needed.

@Aklapper: so, I think this is a MediaWiki-Core-Snapshots

So I much more likely doubt the original meaning of this Component:

Issues relating to Special:Export and Special:Import.
This project is part of the core MediaWiki software itself.

IMO such tags which "just track some random Special pages, no code projects happen" should be merged with MediaWiki-Special-pages

In T123313#2906329, @Shizhao wrote:

To solve this problem need to start from two aspects:

1. How to solve the current timestamps error,

Probably some maintenance script is required.

1. How to prevent the same problem again in the future

The solution is what https://meta.wikimedia.org/wiki/Importer says: avoiding importupload as much as possible. There is almost never a good reason for importupload. I don't know who gave out so many import flags, but you could ask the stewards to remove them all. As long as new imports keep being done in the same (incorrect) way, there is little gain in working on a fix for the data.

I don't know who gave out so many import flags, but you could ask the stewards to remove them all. As long as new imports keep being done in the same (incorrect) way, there is little gain in working on a fix for the data.

Jusjih? (unfortunately the steward right of this user was removed in Dec 2015)

In T123313#2907192, @Nemo_bis wrote:

In T123313#2906329, @Shizhao wrote:

To solve this problem need to start from two aspects:

1. How to solve the current timestamps error,

Probably some maintenance script is required.

1. How to prevent the same problem again in the future

The solution is what https://meta.wikimedia.org/wiki/Importer says: avoiding importupload as much as possible. There is almost never a good reason for importupload. I don't know who gave out so many import flags, but you could ask the stewards to remove them all. As long as new imports keep being done in the same (incorrect) way, there is little gain in working on a fix for the data.

see https://zh.wikisource.org/wiki/Wikisource:%E5%B0%8E%E5%85%A5%E8%80%85 (Requests for import), all permissions are community consensus.

In T123313#2929815, @Shizhao wrote:

In T123313#2907192, @Nemo_bis wrote:

In T123313#2906329, @Shizhao wrote:

To solve this problem need to start from two aspects:

1. How to solve the current timestamps error,

Probably some maintenance script is required.

1. How to prevent the same problem again in the future

The solution is what https://meta.wikimedia.org/wiki/Importer says: avoiding importupload as much as possible. There is almost never a good reason for importupload. I don't know who gave out so many import flags, but you could ask the stewards to remove them all. As long as new imports keep being done in the same (incorrect) way, there is little gain in working on a fix for the data.

see https://zh.wikisource.org/wiki/Wikisource:%E5%B0%8E%E5%85%A5%E8%80%85 (Requests for import), all permissions are community consensus.

Anyway I sent e-mail to @Jusjih about this issue, but still no reply

In T123313#2929815, @Shizhao wrote:

see https://zh.wikisource.org/wiki/Wikisource:%E5%B0%8E%E5%85%A5%E8%80%85 (Requests for import), all permissions are community consensus.

The community should either

• grant such permissions for a shorter time; or
• operate under a strict policy to ensure that the permission is given only for specific, absolutely needed and limited imports, not for operations which disrupt edit histories; or
• acknowledge that it's more important to preserve edit histories than to do whatever they're doing with importupload, and therefore give up all such local rights.