Posted by Paul Furman on 02/28/07 20:45

I don't know, maybe this isn't strange but someone else set up the
shopping card coding I'm working with, the way it works is to get the
time() in seconds like 1172693735 and that's the shopper_ID number and
the shopping_cart_last_modified number is generated the same way once
they check out... then an invoice number is generated by subtracting the
two numbers (shopper_ID is older from when they registered). Is this
strange or bad or clever and efficient? Or maybe I'm misreading the
code. While unlikey, it seems possible to get the same number twice.

And the numbers end up being almost completely random, with no sequence
for sorting or clue of the actual date. In fact the invoice number is
only generated on the fly when composing a confirmation email and on the
admin interface to the shopping carts.

Maybe it would make sense to concatenate the numbers... at least that
would be sequential but would be a huge number... I'm setting up credit
card payment and we'll need to use the invoice number to find
transactions for issuing credits and such.

1172693735 + 1172693735 = 11726937351172693735 = too long!

Surely we'd never have more than 9999 invoices a year so the invoice
number could just be 070001, 070002, etc.

Or start counting time on 1-1-07 so the number is 37 years worth of
seconds smaller like: 5,088,686 I'm not too concerned about two people
checking out at the same second. That way I don't need to add a new
field to the database or change much. That would grow by 10,800 seconds
a year and 432,000 in 40 years: as long as I'll be alive :-)

Is that a sensible way to approach this?

//seconds since the Unix Epoch (January 1 1970)
print time();

//seconds since 1-1-07 (-37 years))
print " ".(time()- (31556926*37));

[Back to original message]