Joe Abley wrote:
On 8 Jan 2004, at 11:35, Owen DeLong wrote:
I don't see any real reason for Verisign to do this, other than possibly some lazy coding in automation tools (that SN is slightly easier to use as a timestamp in automation than one that is the encoded date). It doesn't provide the functionality they are striving for.
If they are going to do zone updates every 15 minutes, then that's 96 serial bumps per day. They could fit that in the the two-digit nn in YYYYMMDDnn, but it wouldn't leave an awful lot of room for any additional ad-hoc serial bumps that might be necessary to address operational problems.
YYYYMMDDnnn exceeds 32 bits for contemporary values of YYYY, so that's not a viable alternative. YYMMDDnnn would work, but has Y2K-ignorant connotations (not that that's particular relevant, post Y2K). Using a second-counter from the unix epoch seems like a perfectly reasonable solution to me.
If it doesn't matter to anybody, and nobody cares, and the value (current and proposed) is irrelevant, why not just add "1" to the current value and stop worrying about it?