Re: SSN's possible new Y2K problem?

seatlejohn raises an interesting point.
But what if instead of makeing ssn 10 digit's
at some point off in the future the SSA decides
to change the base of the number from 10 to say 16 (hex)
then we would have SSN's with ABCDEF in them?

Should hex values be declared as VARCHAR2 in databases?
I guess that it doesn't matter if the column is VARCHAR2
or NUMBER. Geez I am cinfused now.

Comment on Re: SSN's possible new Y2K problem?

Replies are listed 'Best First'.
Re: Re: SSN's possible new Y2K problem? by demerphq (Chancellor) on Aug 14, 2002 at 13:01 UTC
I seriously doubt they would go to hex. Base 36 perhaps, but certainly not base 16. The work required to go from decimal to base 16 is the same as to base 36, but the latter provides far more unique values. BTW, base 36 = `[A-Z0-9]` Its nice to think that perhaps they might even go to base 62 or base 64, but the likelyhood of error mistaking a lowercase letter for an uppercase one (or vice-versa) makes me think that that is even less likely than hex. Yves / DeMerphq --- Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)	[reply] [d/l]
Re: Re: Re: SSN's possible new Y2K problem? by seattlejohn (Deacon) on Aug 16, 2002 at 23:08 UTC
Now I'm getting waaay OT, but I have to admit I've sometimes wondered if using base 36 for identifiers is such a great idea, because it's so easy to visually confuse 1 (one) with I (India) and 0 (zero) with O (Oscar). And if your letters could occur in either uc or lc form, the lower-case l (lima) is a problem too. That leaves us with 33 characters, just one above the nice round 2**5, so I've occasionally been tempted to argue for base-32 identifiers consisting of `[0-9A-HJKMNP-Y]`. Of course, the encode/decode logic would probably be a lot less efficient than base-36 ;-)	[reply] [d/l]


Welcome to the Monastery
	PerlMonks