Most open-source projects have a bug tracker, and bugs are numbered sequentially. Thus, knowing the highest existing bug number (GBN) is an important piece of information if you’re looking for what you believe is a new (globally, not just new to you) bug.
You do a search for bugs, and one of the things you see is their number. If you know roughly what the GBN is, you can tell at a glance whether the bugs in your search results are new or old. That will give you important information, as a bug from ten years ago, from a deprecated version that won’t even run with your current libraries, etc. is probably not your bug.
Of course, technically knowing the GBN isn’t sufficient. You must also have some vague idea of the reporting cadence. That is, if GNB is 600K, and you’re looking at bug 550K, the rough time to accumulate the intervening 50K bugs could be large or small. And the cadence changes, probably following an elliptical orbit (speeding up close to release, slowing down at the midpoint between releases).
The question is, would it make sense to change how bugs are numbered? Would it make more sense to have bugs numbered like: YYYYMM-NNN? Adding in DD would probably be too fine-grained, but months probably fit well for most projects.
Bug numbers do not have an inherent meaning. They are already security-compromised in terms of giving away the timeframe they were filed. (That can be avoided by squirreling away some numbers and filing them late, but it’s unlikely to be done in open source. Even if it were, you could still squirrel some date-stamped bug numbers.)
You would lose guess-the-date-for-bug-N contests, though you could technically still hold one, it would just be using bug numbers people don’t refer to as often.
You might also gain a benefit: developers would have the date-of-filing staring them in the face every time they referenced a bug. I don’t think that would really matter; software gets built as best it can. Most unfixed bugs aren’t from laziness, but from difficulty, lack of information, and lack of time.
The other side of that is the users who will say, “this bug is five years old.” They already exist, though, so it doesn’t seem like this adds to that problem.
But having a year-month-numbered bug can, in some cases, give an immediate idea of a project’s size. A bug like YYYYMM-1 won’t, but a bug like YYYYMM-2468 will. They’re getting at least thousands of bugs per month.
There might be some technical issues. Will a bug database handle a lookup as easily when fragmented into years and months? Should there be that dash or should it be YYYYMMNN? Will people think the Ns are days?
What other benefits would this scheme achieve? Could you type MMNNN for the current year in a search? Or NNN for the current month? Will people get frustrated when it’s the first day of the month and their bug now needs to be typed out? Could you use some shorthand for that case?
I think using partial dates rather than purely sequential bug numbers (at least as an alias; there’s probably value in keeping the regular, sequential numbers, too) may have some use, but what do you think?