I all
I have written a bash script for compare two date. One of those is a result of query, and another is current date.
I have a problem with the format, because the first is 09/12/19 18:50:30 but for having this result I have to do
d1DB=$(date -d "$valData" +'%m/%d/%y %T')
and the second is 09/12/19 18:52:05
currenttime=$(date +'%d/%m/%y %T')
I want inform you that the first date is taken as string from DB, and after I convert it in date with parameter +'%m/%d/%y' and NOT +'%m/%d/%y' because I have month and day reverse
How I can resolve this problem of format?
How I can compare two date, so I can verify when the diff is more or less of 3 minutes?
Personally, I always convert formatted time strings to a unix timestamp before doing time operations, and then covert the resulting time stamp back to a formatted time string if I need one.
Also, in all the databases I use on a regular basis, the dates and times are all stored as unix time stamps in the tables.
As an example, last week I wrote some code which estimated the load on the server and modified the DB queries based on the load and then calculated the estimated time to completion of that project in the log files, updated every minute. All the calculation were based on unix time stamp except the final log file entry, which I converted to my local time format for easy reading.
There are lot of people who will write code to do time operations on formatted time strings; but this is "a kludge" in my view, as time operations should be performed and stored as a unix time stamp and when a human wants to read the time, we then covert the time stamp to a local format based on the time zone of the user.
Also, let's say that you are in Brazil and your friend is in Japan. You want to do the same task at the same time (on a computer). It is best to specify the exact time as a unix time stamp, so you both will use the same time; and if you want to know the "formatted time" you can covert that time to a time string appropriate for your time zone.
Anyway.... that is my suggestion. That is what I always do...... all operations (processing) in unix timestamps.
Your two parameters (which I have wrapped in ICODE tags for you) appear to be the same to me. Notwithstanding, I'm wondering if the table column in question is a string or a date. The output of DESC your_table_name ; will should you what it is defined as. If it is stored as a date field, then we can probably adjust the SELECT statement.
Can you show us your table structure, the query and some sample output that we need to logically compare? The way to do it will be to convert it to Unix time (number of seconds since the Epoch, 1/1/1970) as Neo says, and then it is a simple subtraction.
You store the date and time as a formatted datetime string.
This creates a mess.
It is best to store all your dates (as I said) as an integer(11) not a string but since you are storing as a datetime string, that's OK... you can deal with this easily:
The first thing you need to do is to convert that datetime string to a unix timestamp, for example (like this):
query="select UNIX_TIMESTAMP( 'YOUR DATETIME STRING HERE') FROM TemperatureLOG order by TimeLog DESC LIMIT 1;"
I did not test it, but you get the idea. UNIX_TIMESTAMP() will take a formatted string and convert it to unix time.