I'm working on a GWT app where I need to support the following scenario:
The server is located in time zone A
The client's browser is set to time zone B
The GWT app is configured to display date/time in time zone C
Since GWT does not support Calendar and the native support for time
zones in javascript is non-existent I can't think of a nice and clean
solution to this problem.
Have any of you done something similar or do you know of any good
utils I could use?
Thanks!
In my experience, the following best practice significantly reduces complexity and confusion when dealing with dates and timezones in gwt:
Whenever operating/storing dates within the application, treat all dates as milliseconds since epoch in GMT timezone. You can store them as string or int, it doesn't really make a difference.
Whenever displaying the date to the end user, format the date using appropriate timezone.
For your case, when you create a date on the Server (timezone A) convert it to milliseconds since epoch in GMT before sending it to the Client. On the client, use DateTimeFormat (or write your own date formatter util) to convert it into either timezone B or timezone C as appropriate.
You can't change the GWT timezone, hence all java.util.Date's has the browser timezone. You will need to handle the current timezone setting manually.
I see 3 options:
You manage the timezone conversion yourself.
You override the serializer/deserializer of java.util.Date like in this post. And maybe using a custom java.util.Date implemtation, that overrides the getTimezoneOffset(). This approach requires recompilation of the GWT API!.
You implement your own Date, either by extending java.util.Date (like in option 2) or wrapping it with some timezone object. In this option CustomFieldSerializer's may still be usefull, but there is no need for recompiling the GWT API.
I would prefer option 3. At least until GWT RPC maybe someday will support for overriding the CustomFieldSerializer's
Usefull date/time formatting hints.
Dave Paroulek's answer is the right approach. If you want to see an example of this, we created widgets that work independent of TimeZone and process the values on the server-side where we have all of the TimeZone information we need.
UTCDateBox - Wrapper around the GWT DateBox and always chooses the date at midnight in GMT and represents the value as a Long instead of a Date.
UTCTimeBox - New widget that always chooses a time as millis since midnight, independent of timezone, also represented as a Long.
UTCDateTimeUtils - Server-side code that splits a Date into 2 Long values appropriate for UTCDateBox and UTCTimeBox in a given TimeZone and combines them back into a Date in a given TimeZone.
Here is an example of the date the time controls being used together.
Blog article describing their implementation.
These widgets are available on GitHub.
I'm assuming you are using RPC calls for server-client communication here. Also assuming that you don't care about timezone B, and you know what timezone C is on the server.
You have a few options here:
Calculate the desired date in the server (no Java limits on what you can do there) and send it in a String to be displayed to the client, so you don't have to do anymore transformations on the client.
or:
Calculate the offset between timezone A and C on the server, apply it to all the Date objects you are passing to the client and just display them on the client.
if for some reason none of these were valid for you
Calculate the offset, send it to the client and apply it to any Date you receive from the server by transforming to ms, adding the offset and then creating a Date object again.
see this demo project
GWT timezone demo project
I created a GWT-compatible Java version of the jsTimezoneDetect Javascript library specifically for this purpose. This should provide a (very good guess of) the timezone name purely on the client side. Feel free to try it out and let me know if it works or doesn't work for you.
Related
I am looking for the most simple and cleanest way to fix the timezone for all dates in an Android app. The idea is to have the app running as if the user were in another timezone. Let me clarify what I am looking for:
Let's say the user's phone is set to America/New_York then I would like my app to show all dates (are in UTC) in the Europe/Amsterdam timezone, regardless of the timezone that is set on the phone itself. And if I make a comparison with a new Date() it would be very nice if that new Date() is also in the current time of the Europe/Amsterdam timezone.
After searching the internet for solutions, I started to get the feeling that I will have to update every place in my app where a Date is used and force the use of the target timezone, like the solution of this stackoverflow post: Converting UTC dates to other timezones
Does anybody know how to get this done in a more easy and cleaner way?
The answer for anyone using java.time, the modern Java date and time API.
java.time does not include an option for setting the JVM default time zone. And wisely so. It’s not something you should want to do. By doing it you affect every program running in the same JVM, and also every part of your program and other program in the JVM may set it differently, ruining your intentions.
Avoid the need
In your time operations be explicit about which time zone you want, and you will always know what you get independently of the JVM setting. Example:
System.out.println(ZonedDateTime.now(ZoneId.of("Asia/Dushanbe")));
Example output:
2021-05-09T00:36:25.171213+05:00[Asia/Dushanbe]
System.setProperty
If you have already written a lot of code relying on the default time zone of the JVM, the hack to set it is:
System.setProperty("user.timezone", "Australia/Tasmania");
System.out.println(ZonedDateTime.now());
This just printed:
2021-05-09T05:38:03.568350+10:00[Australia/Tasmania]
It’s not very robust, though, for the reasons mentioned in the beginning.
If you want validation of the string you are passing, use:
System.setProperty("user.timezone", ZoneId.of("Australia/Tasmania").getId());
Disclaimer
It seems from your question that you are already using the old, poorly designed and long outdated java.util.Date class and friends. I still wanted to post the answer for users who have the option to go modern. (You may also use each of the two ideas presented with the out-dated API.)
I would try TimeZone.setDefault(TimeZone) like in:
TimeZone.setDefault(TimeZone.getTimeZone("Europe/Amsterdam"));
(advice to check returned time zone, getTimeZone does not throw exception for unknown time zone - or use ZoneId instead of the String)
see TimeZone (this also mentions the user.timezone system property)
but I am not an android programmer/user
I have an application which is used by all over world. But the application server is present in India.
One of my application features is
**create template using date
So, for that I have to store the client systems date & time.
But I need to store date time based on Client side or server side in single column in database?
What is the best approach to do this?
I think you have a few options here, depending on how you wish to delegate responsibility and how the templates will be used.
The simplest solution is simply that the client submits the date & time and you store it as is with no time zone information. This however assumes that the template would only be used in the same time zone, or that it is acceptable to have the same date & time visible everywhere according to where it was created (probably not the best approach for a worldwide system)!
Another option is that you store the value as UTC. Then you can either:
Make the client responsible for converting to their local time
zone
Store the offset / time zone separately and include it in the result
This is probably the best approach
Or another option is to store the date & time together with the time zone it was created within. Then you might have to convert between different time zones either on the server or client side if you need a different one.
I have a list of Java time zone ids and want to convert these into Python time zone ids. One way to do it is to build a dictionary manually which maps Java time zone ids to Python time zone ids. Is there any other way by which I can do this? I am working on python 2.7.6.
There's nothing to convert. Both Java and Python (via pytz or dateutil) work with the same set of time zones from the tz database.
If you see differences, then it may be because one of your environments doesn't have a current version. New time zones are released occasionally, but old ones are never removed. They're just converted to links to maintain backwards compatibility.
If you have a specific example where you see a zone in one but not the other (which shouldn't happen), then please update your question with the details.
See also: the timezone tag wiki.
http://tutorials.jenkov.com/java-date-time/java-util-timezone.html
Python - Pytz - List of Timezones?
Pass the time and string of timezone. Hopefully Python contains the one you're looking for
I have a Java web-application. In some places there is showing of dates. I want to display the date according to user timezone. How do I create a date for the show if I know the timezone the user?
I use the class Date.
Any help would be greatly appreciated.
There is no standard way to do this. On client side, you may capture time using Java script and send that information to the server. On server side, you can covert the time to Coordinated Universal Time.
Use GregorianCalendar rather than Date when you have any requirements besides basic display. You can create one for the current time by time-zone using new GregorianCalendar(TimeZone).
I need to add timezone information to a db table with user maintained locations. The data will be accessed mostly from Java code but there is also some PL/SQL and Win32 (Delphi) code which needs to understand the timezone information.
It seems straight forward to use the id from java.util.TimeZone. Java can easily convert that (obviously), Hibernate has built-in support for it and apparently also Oracle understands those timezone ids:
select TZ_OFFSET('Pacific/Marquesas') from dual.
The problem is: the timezone ids do not seem to be compatible with the Windows Timezone DB. For example, the java.util.timezone id "Pacific/Marquesas" (-09:30) is not in the timezone picklist in Windows. The registry does not contain it at all; see
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Here I can only pick either -09:00 or -10:00. So, if I were to store the timezone like this, how can I get to the actual offset/DST infos in Windows (without Java)? Hopefully this does not require a mapping table which I have to keep up to date whenever it changes. Is there a globally accepted standard which works better than the java timezone id?
Update
The timezone info is used in combination with DATE columns on the database. Those columns contain local date/time values. If a location can be associated with those values, the location's timezone enables me to convert the date/time value to UTC or any other timezone whenever needed.
I realize that instead of DATE a TIMESTAMP_TZ data type or something similar would be more appropriate. However, this would require a data migration (for which the TZ is required again) and is not supported by the legacy applications which also work on the data (unless a lot of code is changed). The problem is almost the same if I had to convert the values to UTC.
Bottom line is I need to keep the DATE values in local time but I need to know for some of them which TZ that means.
I can give a little background, if not a real answer.
Many systems use the Olson implementation of timezone data. So those names work in many systems (most Unix, Java, Oracle I think). Microsoft does their own thing.
I see at the bottom of that Wikipedia link there's a reference to some mapping to the Windows world.
Good luck!
I realize this is not the best way to do it, but it might be sufficient in your case. Without knowing all the requirements I can't tell.
What do you need to use the time zone information for? Just to present the time with the correct offset and maybe also the name of the time zone?
You could continue to use Java to determine what the offset of the user is by looking up the user's selected time zone using Java. Each time the user logs in record in your database what the offset currently is. Then other apps can look at this information to determine how to format the time.
This assumes that users who regularly login are the ones that this needs to be done for. If that's not the case you could run a daily job to lookup the time zone for each user in Java and record the offset currently in effect.
Hackish, agreed, but the only other way I see is to maintain a mapping. And what happens when someone selects a time zone that you don't have a mapping for?