Really old accounts do not have this information. The registration timestamp was introduced somewhere in 2004.

I.e. my account [[de:User:Raymond]] is from 2003.

This is the editor survey's fault then. It's been known for a long time that the registration field is not set for every user (there are a few other fields in other tables that behave this way, such as revision length), so things like the editor survey have to account for the possibility that it may not be available.

It's also possible that this is a bug in an API module used by the editor survey, but I'm not at all familiar with it so I can't tell.

WONTFIX these accounts are from before it was stored in the db and there is no
decent way to automatically fill these in.

This is most likley a dup but I can't be bothered looking atm.

Should be INVALID then, not WONTFIX. Is there bug open for survey module or can we re-categorize this one?

For the survey it's supposed to be already fixed. If the devs don't want to fix the accounts themselves, it may be fine, but this issue should be documented so that API users won't fall for this in the future.

Devs can't "fix" this, the information just isn't there. System administrators could throw some arbitrary values in the fields.

(In reply to comment #6)

Devs can't "fix" this, the information just isn't there. System administrators
could throw some arbitrary values in the fields.

Time of first edit minus 5 minutes should be good enough :)

(In reply to comment #4)

Should be INVALID then, not WONTFIX. Is there bug open for survey module or can
we re-categorize this one?

There was discussions with filling it with other data, such as their first edit but I believe it was decided not to because that wouldn't be "real" information.

This bug can be *partially* fixed.

(data taken from cswiki db, so it won't be accurate to second wikimedia-wide, but at least the date should be enough descriptive)

select min( user_registration ) from user
= 20051222111612

select min( log_timestamp ) from logging where log_type = "newusers"
= 20050907222547

So at least that 3,5 months gap could be fixed by some maintenance script.

The bug was in the API called by CentralNotice. It returned a string for most users and the integer 0 for users like Amir, which caused a Javascript error. I fixed this by casting the result in the banner code and Nimish has fixed it in the API so that it returns a string in both cases.

Not sure if there is a good solution to the broader problem though.

Retitled bug and changed component to match the actual problem that
needed resolving. If Nimish has the revision number for the fix, it'd
be nice if he could add it.

This bug is not about the survey issue, which is already fixed. It's about preventing such issues in the future.

(In reply to comment #12)

This bug is not about the survey issue, which is already fixed. It's about
preventing such issues in the future.

Which issue do you think has not been properly addressed and is likely to reoccur? Do you have an idea of what a solution to this would look like?

(In reply to comment #13)

(In reply to comment #12)

This bug is not about the survey issue, which is already fixed. It's about
preventing such issues in the future.

Which issue do you think has not been properly addressed and is likely to
reoccur? Do you have an idea of what a solution to this would look like?

This caveat should be documented somewhere, that would probably be enough.

Done on trunk in r87981:

• ' registration - Adds the timestamp of when the user registered',

+ ' registration - Adds the timestamp of when the user registered if available (may be blank)',