I did some work repairing a gift certificate for NowStudio.co that a previous coder had created. The certificate is quite fantastic and keeps track of purchased certificates in a database. However, much of the code was written for PHP4 and had logic bugs that needed to cleaned up. A nice fun side project to work on.

The Problem.

The original coder used PHP’s rand() function to generate a number between 10,000,000 and 99,999,999 for the serial + the purchaser’s full name.

Not Unique. The obvious reasoning being that they didn’t want someone to be able to guess a certificate number and redeem a previously payed for certificate. Makes sense. However, there is a key flaw with creating serials this way. Random != Unique. There is the off chance, given time, that two certificates will be created with the same serial!

Using Names. The original coder recognized there was a chance a duplicate serial could be picked. They decided to use both the serial and the the buyer’s first and last name as the unique entries. Excellent idea and certainly seems to solve the problem. However, names tend to be unpredictable and unreliable. For instance, some last names are multi-part (Elfriede Von Kosh), have punctuation (Patrick O’Conner), or contain diacritic marks (Soňa Novak) among other things. This can cause unreliability with the app.

The question.

How can I create a better method of serializing the certificates?

Here are some requirements I came up with:

• It has to be unique
• Cannot be re-used
• Non-continuous
• Not guessable
• Shouldn’t need to query the database to verify the serial hasn’t been used
• Meaningful
• Manageable in length

The Solution.

I decided simple solution is to use the full date/time + 4 random digits. For example this moment would be 2013-02-17 at 17:11:32 + 8345  or in string format  201302171711328345.

The Date. This serial has the benefit of telling us the exact moment it was generated. I use a 24-hour clock keep the length of the string always the same as well as to avoid the accidental repeated digit twice a day (9am and 9pm), that would be quite awkward. It would only increases the odds of getting a duplicated serial.

The +4 Digits. Using just the date and time down to the second I was still bugged that in theory two users could land on the page at the same moment and be served up the same serial. That’s why I felt the necessity to add the +4 random digits to the end of the string. While in theory it may be possible to still to generate duplicate serials, this makes it rather unlikely. During the save to the database we can always do a double check if we feel it is needed.

The Code.

For the landlubbers that want to use use this method of creating a serial, but don’t want to write it themselves – Here is what it looks like in PHP:

$serial=date("YmjGis").rand(1000,9999);

Too simple? Know a better solution? This only would work for small-medium sites.