otuatail Posted November 9, 2015 Share Posted November 9, 2015 Hi This is a simple website. It doesn't use objects. I use time() and date() Also I may need to add this value into MySQL and I wouldn't know how to add a date object into the query. Quote Link to comment Share on other sites More sharing options...
requinix Posted November 9, 2015 Share Posted November 9, 2015 Subtract 30 days from a date30 days of elapsed time or 30 days on the calendar? There is a difference. Are you using times with the dates too? And most importantly, what code do you have written so far and what kind of problems are you having with it? This is a simple website. It doesn't use objects.That is no excuse. I use time() and date()I'm a fan of those functions too, but there are some things DateTime can do better. Also I may need to add this value into MySQL and I wouldn't know how to add a date object into the query.Depends how you store the date. The only two good options are as a DATE/TIME/DATETIME or as a Unix timestamp (which would use an INT or larger). For the former you just create a string in the "YYYY-MM-DD HH:MM:SS" format (eg, Y-m-d H:i:s), for the latter you keep the integer values that functions like time() and mktime() and strtotime() return. Quote Link to comment Share on other sites More sharing options...
Psycho Posted November 9, 2015 Share Posted November 9, 2015 To add to requinix's response: Since you mention "time" in your post, it is very important to know whether you want to subtract 30 calendar days or if you want to subtract 30 days (i.e. 30 x 24 hours). It will likely depend on "how" the value(s) are used. This is due to Daylight Savings time that is used in some parts of the world. Let me give two examples that would need to be handled differently. Scenario #1: Let's say you want to run a report from a specific date/time back 30 days. If the user expects to run the report at 5PM (close of business) today to see a report of all activity from 30 days ago at close of business - the logic needs to subtract 30 calendar days, but set 5PM as a constant. Scenario #2: An application that needs to track the status of an activity over very specific times would likely be different. For example, say there is an experiment to measure the results over hours/weeks/months. If I wanted a report for the results over 30 days it would need to take into account time changes due to daylight savings. So, if I wanted the report to end at 5PM today, it would need to start at 6PM on the calendar day 30 days back. That is because last weekend we set the clock back an hour last weekend (i.e. we repeated the 1AM to 2AM hour). 1 Quote Link to comment Share on other sites More sharing options...
Barand Posted November 9, 2015 Share Posted November 9, 2015 IMHO a unix timestamp is not a good option. If when you need to browse your data in the table it makes it almost impossible to know what the actual date/time value is and needs conversion to DATE/TIME type before you can use the majority of datetime SQL functions. 1 Quote Link to comment Share on other sites More sharing options...
Psycho Posted November 10, 2015 Share Posted November 10, 2015 IMHO a unix timestamp is not a good option. If when you need to browse your data in the table it makes it almost impossible to know what the actual date/time value is and needs conversion to DATE/TIME type before you can use the majority of datetime SQL functions. It is my understanding that a timestamp is the correct type if the "event" is one that must be normalized based upon a given user's timezone. A datetime is one that would be statis regardless of timezone. For example, if I am recording the date and time that someone is born, you would display the exact same date and time to a user regardless of their locale (a datetime type). Otherwise, my birthday would be a day earlier if I traveled to Europe. Conversely, if I was to record the date and time of when a specific event was to occur, such as the super bowl, I would use a timestamp so it could be displayed as to the correct date and time relative to the user. Quote Link to comment Share on other sites More sharing options...
Barand Posted November 10, 2015 Share Posted November 10, 2015 Your understanding is correct. However, that refers to the MySql TIMESTAMP type which has the same format as DATETIME type (but a smaller date range). In my comment above I stated "unix timestamp" which is an INT (eg 1447148711). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.