I am sure this is a very very common problem.
I have a struts action that uses a common jquery datepicker calendar to select a date for my code to use. Problem is that our production servers live in Texas on CST, but I am in DC on EST. My web browser sends 12/6/11 12:00 AM EST (midnight) and it is interpreted as 12/5/11 11:00 PM CST by the server.
Any recommended ways to fix this?
Should I send the local browser's timezone as a parameter to my web services code?
If possible, always deal with UTC times internally in your code (and especially in communications between components). Convert to local time at the last possible moment before display, where you know what the user's time zone is.
In your case, convert the timestamp to UTC in the browser before sending to the server.
If you're doing something like setting appointment times in the future, beware of Daylight Saving Time, where everything gets shifted by an hour twice a year (but UTC doesn't). For example, the user will expect that setting an appointment for "next Tuesday at 2:00 pm" will work even if next Tuesday is a different UTC offset from now.
Related
When using Magnolia CMS' DateFieldDefinition class: if my computer's current date is not matching the saved date's Daylight saving time, the saved date's time will be incorrect.
The relevant class: info.magnolia.ui.form.field.definition.DateFieldDefinition.
The relevant Vaadin component "Date and Time Input with DateField".
Another person seemed to have the same problem.
EDIT: Magnolia CMS appears to have a ticket about this issue already
Example:
In this example, I am running Magnolia CMS locally.
My computer's current date is Oct 17th, 2016
My computer's TimeZone is "Switzerland/Zurich"; hence I am on GMT+2 for the current date (summer time for my time zone)
In Magnolia Admin Panel, I save a date on Nov 3rd, 2016, hence that date is in winter time for my time zone, so GMT+1
That's where it gets interesting:
I change my computer's date to Nov 2nd, 2016, hence I am on GMT+1 (winter time for my time zone)
In Magnolia Admin Panel I open that date, it shows one-hour less.
Illustrations
The date/time implementation in Magnolia 5 was (and possibly still is) rather bad because of several issues:
It failed to distinguish between points in time (e.g. Skype appointment with someone possibly in another time zone) and "concept" times (e.g. a note when to make breakfast - it will always be at 7:00, no matter what time zone, so it's not about a specific point in time but about the concept of 7 o'clock)
It saved dates as timestamps although dates are neither timestamps nor time spans. This inaccuracy lead to the next problem:
Since dates were treated as timestamps by Magnolia 5 and timestamps were always handled as "points in time" by Magnolia 5, dates were also treated as points in time by Magnolia 5 although this is always wrong. Dates are always just "concepts" (in above sense), e.g. dates of birth. If I'm born on 1st January 1980, then that's my date of birth, and that is so in every time zone. My date of birth is not 31st December 1979 in another timezone, like it would with the "point in time" semantics mentioned earlier.
Dates and times were saved as instances of Calendar in JCR, that is a timestamp with a timezone. When transferring data from one Magnolia instance to another (Export, Import, Activation), the actual timestamps were copied as they were, they were not converted to the timezone of the target system. This meant that when the target system finally read the values, it may have seen wrong dates and/or times unless it explicitly converted the values.
Magnolia used to use the Browser's time zone for reading dates/times from the user by the Vaadin date/time fields but the server time zone for storing them in JCR. This meant there was always an implicit translation that may or may not have been wanted in the business logic. In many cases wrong values would end up in the repository (e.g. when entering dates of birth), so the later processing based on them had a certain probability of going wrong. In any case it had to be expected that the date/time saved in the repository was not the one the user had entered.
In a support ticket I wrote to Magnolia about these isuees they said they had fixed it in Magnolia CORE 5.4.11, which will be available since 5.5.1. I haven't tested these fixes yet, but unless you use this fixed version I wouldn't recommend to expect a simple solution for your problem, which comes on top of the problems I mentioned above. I did so just to document how little room there is to get the correct behavior for your use case with provided classes unless you needed exactly the use case they had implemented.
One of my business use case requires to recalculate some metrics on date change and also need to cover clients working on different time zones like EDT, IST etc.
Is there any option in Java to get a trigger on a date change and should work for different time zone?
Example: I want a trigger for date change in IST, EDT, GMT, MST, CST etc only. and not all time zones. Is there any jar or a framework which supports this where i can input the time zones and i just get notifications.
I cannot use cron triggers here because it works on a single timezone. Cron expression takes a particular time zone.
Any help is appreciated.
I have a problem that I can't understand. I tried to find the answer a lot of time, but without success.
I work with GWT client side, and Java server side.
Client side, I read dates (java.util.date). And when I send these dates to server side, there sometimes is an hour offset when I receive it.
I know there are many problems with TimeZone. But I think TimeZone aren't responsible of my problem, because not all dates are wrong. To test which dates were wrong, I create a method which create a List of all dates between 1st January of 1900 and today, and which send this list to the server.
When I read the list received in server, here are the results :
All dates are correct from the year 1995 (dates didn't change during sending)
From 1979 to 1995 (approximately): All dates are correct, except 28 days in september / october (from the swith to winter daylight saving time). It's incorrect because of an offset of one hour.
Before : some dates are correct, and some incorrect.
So I tried to add 100 years to my dates client side, send it and remove 100 years server side. And all received dates were correct !
Anybody already had this problem ? And anybody understood this problem ? Any help is welcome.
Thanks !
Edit :
Ok I solved the problem. Read answer of Andrei Volgin to understand the problem. And here is the code which solved it :
// Create date you want
Date date = new Date()
// Get TimeZone of your date
TimeZone timeZone = TimeZone.createTimeZone(date.getTimezoneOffset());
// Adapt your date with the TimeZone
date.setTime(date.getTime() - (timeZone.getOffset(date) * 60000));
// You can send your date to server
// TimeZone server side is "UTC", and all dates received are correct
This is a TimeZone problem.
TimeZone definitions and especially daylight savings rules have changed over the years. If you simply pass the time zone ID or create a time zone using an offset, the browser is unaware of these changes. So the browser simply uses the time-zone offset and current DST setting for this time zone when displaying time. Most of the time this results in a correct time, but not always. This also explains why all dates in the future are correct.
In order to get the accurate conversion, you need to create a TimeZone object using a JSON data string that GWT provides, i.e. use createTimeZone(java.lang.String tzJSON) or createTimeZone(TimeZoneInfo timezoneData).
I have a date stored in a database as a UTC date ('2015-04-24 00:00:00'). When I get this date (using Hibernate) on a server running in the Eastern US Timezone, is shown as the correct date, '2015-04-24 00:00:00'. However, when I get this data on a server running on AWS in the us-west-1 region, which I assume is Pacific Time, the date shows as '2015-04-23 20:00:00'. Does anyone know why this would happen? I assume it has something to do with the date converting to local time, rather than UTC, but how can I prevent this from happening? Thanks!
Short answer: Just convert your Date to utc
Somewhat longer answer: As long as we don't consider relativistic effects a date (or more appropriately named a point in time) doesn't have a time zone. But if you display it as a String there are many variants of displaying it. One kind of variation is the choice of a timezone.
If you don't take special care to use a specific time zone, many programs will choose the timezone that the machine is 'living' in, which is configured on the os level and set to the time zone that is apropriate for the location the computer is most of the time.
Hi i have a typical requirement in my web application, i have to fill a dropdown box with all system timezones and set the selected time zone where from the client is browsing.
Only timezoneoffset is not enough to handle this suituation, since there are two reasons
1.the latest OS having more than one time zone with the same offset
2.If Day light save is enabled or disable(can be detected from Javascript) the offset will vary.
is ther any ways of handling this in Java script?
Short answer:
Use this open source JavaScript project: jsTimezoneDetect. It is based on the code that MK linked here, which is great, but not enough since different regions within the same timezone start their daylight savings at different times. Hemisphere also plays a factor.
Long answer:
One example is the -07:00 UTC timezone which basically has three sub timezones.
US Mountain Standard Time (no daylight saving... this is Arizona)
US Mountain Time (with daylight savings)
Mexico Mountain Time (with daylight savings)
Assuming that you know your user's UTC offset you will now have to check whether your timezone uses daylight savings. Create one January and one June date and check these two dates. If their UTC offsets differ, then you are in a timezone that uses daylight savings.
Say that you have determined that your user is -07:00 with daylight savings, that means either US Mountain Time (America/Denver) or Mexico Mountain Time (America/Chihuahua). How to tell them apart? Well, the date they start their daylight savings differ.
US daylight savings starts in 2011 starts 13 March, and in Mexico it 4th April. So start with Denver and check if 13 march is summer time, no? Ok, check if 4th April is summer time. Yes? Bingo.
Check this: Auto detect a time zone with JavaScript.