> My experience differs from Jorge. > A generic date should do well, and still give you all the date functions. The only > problem with storing dates as a number is doing date arithmetic ( say sending an > email to all people whose birthday is 5 days away) and things like that. It's not a > tremendous burden to overcome, it's just every time I run across dates stored that > way, I always end up writing way more code then I need to. >
Right, and I agree. The main advantage I ever got with storing dates with plain numbers was the sorting. Logic should be handled differently, using real date-handling objects. I still think that the best way to store a date in a DB is with a native date function. I was just pointing out that using a number format was IMHO better than a timestamp. These days I rarely like to depend on any DB vendor, so I tend to keep all the logic outside the DB. And storing and retrieving data is one thing, doing operations is another. I would certainly use Date, Calendar or other classes, whichever was appropiate, when retrieving the data from the DB. Why reinvent the whole thing when you already got the libraries to handle the data? Jorge --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
