1

People can buy an account on my website for 1, 2, 3, 4 or 5 years. I want to store this period in a table. This is my table (for now):

table: users

- user_id        int(11)
- username       varchar(48)
- password       varchar(48)
- time_start     int(11)
- time_end       int(11)

When I add a record, I add the time_start and time_end with:

UNIX_TIMESTAMP(NOW()) / UNIX_TIMESTAMP(NOW() + INTERVAL 1/2/3/4/5 year)

Is this the best approach? To store this data with a UNIX timestamp. Or should I use just regular datetime fields? Is it a good idea to store UNIX timestamps in an integer field? And is a length of 11 enough? I've tested it, and it works. I've chosen it because UNIX timestamp is in UTC and I use a 'time ago' function on my website (it displays the time like '2 seconds ago', '3 minutes ago', ... and if I store it in a datetime field it all goes wrong...)

I'm reading about the year 2038 problem (https://en.wikipedia.org/wiki/Year_2038_problem). Will this be a problem for me in the future?

With regards, Sam

PS: Sorry for my English, I hope my problem is clear enough!

samleurs
  • 146
  • 1
  • 11
  • Probably a duplicate of [Should I use field 'datetime' or 'timestamp'?](http://stackoverflow.com/questions/409286/should-i-use-field-datetime-or-timestamp) – David White Apr 25 '16 at 17:48

1 Answers1

0

Storing as a datetime will be better for the '2038 Problem,' if your current setup actually persists that long (unlikely), and in my opinion, makes things pretty easy to handle, and easily human-readable. Is there a reason you are hesitant to use datetimes?

And your English is just fine!

3nails4you
  • 112
  • 1
  • 9