• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

UNIX Time?

J

jbubrisk

Senior member
Hi everyone,
A software product my company has uses UNIX time, which has resulted in some great annoyances. I was trying to create a date field within the product to store birthdates, but I couldn't do it because it was using the UNIX time to store the dates. In other words, I couldn't do it because anyone born nefore 1970 wouldn't be able to put in their birthdate. As a result, I had to use a text field to store a date. Can anyone tell me the exact reason for using this method of storing a date time? It seems like it would eventually lead to enormously large numbers, which would be cumbersome to store, not the mention the obvious fact that reading the time requires a conversion. Any thoughts?
 
What sort of application is this? You could just use a 32 bit integer and represent the date like 19601231. It would take up less space than the text field, which would be 8 bytes long.

EDIT: This isn't the question you asked, sorry 🙂 To answer your question, I have no idea!

 
Like any data format, you pick what works with your application best. If you know that the dates you're dealing with will be in the supported time frame, why not use UNIX time? It's certainly easy to handle.
 
Obviously a date format which has the zero point in 1970 is not suitable for storing birthdates.

Fire those idiots.

Don't blame Unix. That "format" is not a format, it is a representation for the internal machine clock only.
 
Unix times sole purpose is, Geekiness. Who doesn't want a time system that starts when there product was born? Really, I think that is the only great significance to it.
 
Storing a negative value won't work as software hind it might make the assumption it is positive - if it isn't already unsigned in the product in question.

Storing a negative value also doesn't solve the problem since there are people born before 1970 - 2^31 seconds.

Clearly this field with this data type in it's current representation cannot be used. Period.

Please remember it is the original poster's idea to use this to represent date of birth. It doesn't work. The authors of this product have not intended for this field to be used for anything but the current time. It is not a database field format.

If nothing else depends on it, you can redefine the meaning of this field to mean days since 10000 B.C. so that you can keep the same data type.
 
Originally posted by: uOpt
Storing a negative value won't work as software hind it might make the assumption it is positive - if it isn't already unsigned in the product in question.

Storing a negative value also doesn't solve the problem since there are people born before 1970 - 2^31 seconds.

Clearly this field with this data type in it's current representation cannot be used. Period.

Please remember it is the original poster's idea to use this to represent date of birth. It doesn't work. The authors of this product have not intended for this field to be used for anything but the current time. It is not a database field format.

If nothing else depends on it, you can redefine the meaning of this field to mean days since 10000 B.C. so that you can keep the same data type.
Click to expand...

Did you read the article? You can use 64 bit signed numbers. Nobody is too old for that date range.
 
Off topic, but some of the comments in that Wikipedia article are hilarious.
Using a (signed) 64-bit value introduces a new wraparound date in about 290 billion years, on Sunday, December 4, 292,277,026,596. However, this problem is not widely regarded as a pressing issue.
Click to expand...
Oh really?
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top