When I use the OffsetDateTime.now() in my unit tests I receive the same time as I see on my clock hanging on the wall.
But when it comes to deploy app and debug I see this time -2h hours.
How do I deal with this?
Also, how to treat this execution time, if a user can do the same thing and they come from many different places?
How can I execute something now() if I come from other localization?
Use this now method to get rid of dependency on time zone of server. Pass either a ZoneId object or a ZoneOffset object.
public static OffsetDateTime now(ZoneId zone)
Related
How to get client/request timezone in jsp?
Unfortunately this information is not passed in HTTP headers.
Usually you need cooperating JavaScript to fetch it for you.
Web is full of examples, here is one http://www.coderanch.com/t/486127/JSP/java/Query-timezone
you cannot get timezone, but you can get current time from client side.i.e. through javascript and than post back. On server side, you can convert that time to GMT/UTC. The UTC shows the TimeZone.
If you just need the local timezone in order to display local times to the user, I recommend representing all times in your service in UTC and rendering them in browsers as local times using Moment.js.
My general rule is to handle and store times in UTC everywhere except at the interface with the user, where you convert to/from local time. The advantage of UTC is that you never have to worry about daylight-saving adjustments.
Note that if you want to show the age of something (e.g. "posted 3 hours ago") you just need to compare the UTC timestamp with the current UTC time; no need to convert to local times at all.
Best solution for me is sending date/time as a string, and then parse with server's timezone to get a timestamp. Timestamps are always UTC (or supposed to be) so you will not need client's TimeZone.
For example, sending "10/07/2018 12:45" can be parsed like:
SimpleDateFormat oD = new SimpleDateFormat();
oD.applyPattern("dd/MM/yyyy HH:mm");
oD.setTimeZone(TimeZone.getDefault()); // ;)
Date oDate = oD.parse(request.getParameter("time"));
Obviously you can set your specific date/time format.
Is there a way to get today's date and time such that it corresponds to the real world date/time and is not affected if the user has changed the date/time settings on their phone/web browser?
If not, is using a server time the best way to correctly determine today's date on the phone? Or are there other best practices?
if you don't want to use a server time, u can parse the return of gettime() link
Server time suits most of the needs. Then if your server's time is messed up then you will be in problem.
Alternatively, you can use some third party web service to provide you with the time.
For example
https://developers.google.com/maps/documentation/timezone/
Google being a reputed company, the time returned can be trusted to be correct.
I'd never trust a user's device to retrieve time related information.
Get the UTC time from the server and if required, display it to the user converted to his time zone. Here's a so question on how to convert UTC time to local time with JS
This way your stored time will always be ok and in same "format". The only thing that could happen is that the ends up seeing a "wrong" time, if he faked his location / time zone settings. But I wouldn't mind that.
I have tried the following so I can get Date based on my timezone which is "Africa/Johannesburg" or GMT+2:00 but Google servers always return time using its own timezone which is 2 hours behind mine.
I have done the FF:
in appengine-web.xml I have set
<property name="user.timezone" value="Africa/Johannesburg"/>
I have also tried TimeZone.setDefault(TimeZone.getTimeZone("GMT+2:00")); before creating Date object
in the init method of my servlet, I have also tried
#Override
public void init() throws ServletException {
TimeZone.setDefault(TimeZone.getTimeZone("GMT+2:00"));
}
But this thing won't just work. Because JDK date is not thread safe, I am using JodaTime, which works well, In fact when I do new DateTime(DateTimeZone.forID("Africa/Johannesburg")) I get correct time but for legacy issues, I have to store date in JDK date hence have to convert Joda to JDK Date by invoking .Date(), then the time is completely screwed up in wrong timezone.
Does anyone by chance know how to set this without having to subtract the hours difference.
You can't. The system timezone is not changeable. You should store all of your dates in unix time and convert them to a Date or Calendar object using your timezone. I also would not assume that GAE is always going to use the same timezone...
When you save any date in Datastore it will be saved in the timeZone you have set in your JVM, thats why before starting the app I always set it to UTC:
//To avoid difference of dates depending on where the server is located
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Nonetheless when you browse the datastore in the gcloud console it will be shown in your local timezone (probably it gets the browser timezone and adapts the response to you). But when you query it back the calendar date taken in count will be the one you used for saving it (In my case UTC).
My server is in US and I am accessing the application in India through
web browser, in that case what TimeZone.getDefault() will return?
If it returns Time Zone based on India on basis of what it will return?
I have changed in control panel setting to different locale and
different time zone of the system even though it is not changing based
on my settings.
I have written the code as fallows...
def dateFormat = DateFormat.getDateTimeInstance(DateFormat.DEFAULT,DateFormat.DEFAULT,Locale.getDefault())
dateFormat.setTimeZone(TimeZone.getDefault())
It's going to return the timezone of the JVM TimeZone.getDefault() is executed on. So if the application is running on a server in India, it will be something like "Asia/Calcutta".
Default time zone is usually set for host, not user or application. In your case it will be default time zone for a server where your application is running, most probably US time zone.
Try to run command date +%Z in Unix console on server.
This is a matter of 'where this code executes'. If you are talking about a web application which is being accessed by a browser in India, the kind of date you get will be in US. Well, unless you set the proper locale and timezone for the user's session. In frameworks like Vaadin once you call setLocale() on the application it sets the timezone as well, but in other platforms you might have to explicitly use a date formatter with a specific timezone.
I got hopelessly stuck on this task. I get other-than-UTC future date input from user > I need to persist it as UTC time. I tried various ways, but it always ends up like this: (method names are irrelevant)
Could please anybody give me the right direction ?
It looks like you're already doing the right thing in the first line. With slight modification:
DateTime instant = getDeadLine(orderBean, localTz);
DateTime.getMillis() will give you the number of milliseconds since the UTC epoch... so that's what you need to persist. If you need to be able to convert back to local time, you'll need to know which time zone to convert back to of course - either using the same one every time, or storing it along with the UTC millis.
One thing to note is that local dates/times aren't always unambiguous - the same local date/time can occur twice due to daylight saving transitions. You'll need to think about whether that will ever be relevant to you.