Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Regarding date issue in local and server

I am using CST time in my system, from front end through javascript I am sending today date to spring controller. In spring controller through request param I am getting the date and converting to date through @DateTimeFormat annotation and I getting the same date back to the view I am getting the exact date what i am expecting.

But, when I test through my test enviroment which is deployed in amazon server. When I pass the today date and when I trying to get the same date to front end it coming as different date. I have wrote the code that i used.

Javascript:

$http({
        method : 'GET',
        url : urlpath + '/getDate/',
         params: {
          date: new Date().toString("MM/dd/yyyy")

            }
    }).success(function(response) {
    console.log("date is"+response)                                 
}

Java Code:

@RequestMapping(value = "/getdate", method = RequestMethod.GET)   
public  Date getdate(@RequestParam("date") @DateTimeFormat(pattern ="MM/dd/yyyy") throws Exception {                       
    return date;    
}

The date in my local machine is 01-05-2015 23:17 The console statement is Fri May 01 2015 00:00:00 GMT-0500 (Central Daylight Time) no hh mm and ss since I cropped using the datetimeformat annotation.

In, my test environment I am using the same code but the console is priting like the below Thu Apr 30 2015 23:00:00 GMT-0500 (Central Daylight Time)

Can anyone nail out this issue and tell me the rootcause for this issue.

like image 465
Karthik Avatar asked May 02 '15 04:05

Karthik


1 Answers

Time is only HH:MM:SS and that's it. Timezone comes as default from your computer unless your implicitly set it differently. So, as you can see, when you send only time it actually means nothing about what real time is.

There are 2 solutions.

1) Simplest. Whatever you send cast it to the same time zone. For example UTC. Then, whenever you get it - use it as time form UTC. Implicitly. So, every part of your system knows that sent time is UTC and acts accordingly. Never leave it to default. Who knows where (what time zone) one of your computer works.

2) Similar but with more parameters. Send 2 parameters - time and time zone. Works the same - you always have to cast time (again, never use default) - but, at least, you know what real time on the sender side and, in this case, you will see what your test computer time zone is.

like image 191
Izold Tytykalo Avatar answered Nov 03 '22 16:11

Izold Tytykalo