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.
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.
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)
I'm building a mega simple weather Android app using the forecast.io service.
Using the default call of
https://api.forecast.io/forecast/<my_key>/37.8136,144.9631?units=auto
Always seems to give me the forecast at a time that I don't care for - ie, its currently 2.40PM here, and it keeps giving me 3.40AM forecast.
So I then try to use the time param and yet it still gives me 3.40AM, not 2.40PM
https://api.forecast.io/forecast/<my_key>/37.8136,144.9631,1451619638?units=auto
I've validated 1451619638 as my current unix time via the helpful site http://www.epochconverter.com/
Any pointers as to why I can't seem to get MY local current time?
The API returns the timezone and then the offset from GMT. Check those.
The idea of the first one is if you do not provide the time, you will get a current forecast, and all you will have to do is convert it into your timezone. So if they are doing GMT and you are GMT - 8, you simply subtract 8 from the time value.
Both fields are there:
latitude: The requested latitude.
longitude: The requested longitude.
timezone: The IANA timezone name for the requested location (e.g. America/New_York). This is the timezone used for text forecast summaries and for determining the exact start time of daily data points. (Developers are advised to rely on local system settings rather than this value if at all possible: users may deliberately set an unusual timezone, and furthermore are likely to know what they actually want better than our timezone database does.)
offset: The current timezone offset in hours from GMT.
I have been using this API for a while.
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 am writing a Java program using selenium. I need a function that returns a unique date (mm/dd/yyyy) each time it is called. The conditions though are that
It can never return a date it returned before
Is must return a date between 01/01/2071 and 12/31/9999
The program will run many times so all program memory will be lost upon termination. It
must remember the dates it has returned before. See next item
The easiest way to do this is just keep incrementing the date by 1 day each time, so it
needs to remember only 1 date.
Unfortunately I cannot write the last date returned to a file in the system to read it
next time the program runs because I do not have that ability.
The program will be reading data from an Excel spreadsheet so could theoretically store
the latest date in a cell, but the spreadsheet will be open and it does not seem to
have the ability to write to an open file.
Any thoughts? One thing I thought about doing was using a base date like 1/1/2014 at 00:00:00 and then taking the current date, calculating the number of minutes between the two, and adding this as a number of days to 11/31/2070. Unfortunately this would work only a couple of years because then there would be more minutes between the two dates than there are days from 1/1/2017 to 12/31/9999
Any help is appreciated.
Thanks