GWT doesn't serialize Java Date properly. When I tried sending Date created in Javascript through the wire, I found out that dates between April 1st (funny) and 25th October for years before year 1983 get subtracted by one day.
That means that, say, both 1982-04-01 and 1982-03-31 become 1982-03-31 on the Java side.
Given the dates in question, I would guess that this is some kind of DST problem. I've tried googling, and found only one other reference that describes similar problem.
I also tried submitting bug to the GWT team, but curiously wasn't able to find bugtracker for GWT.
So, my questions are:
Anyone else run into this? I'm on GWT 1.7, and would like to confirm if this happens on 2.0 as well.
My workaround was to send dates as Strings, and parse them on server. Anyone knows better workaround?
Assuming that you are using a java.util.Date
Question 1: It seems that it is fixed in 2.0. I've created both Dates above (1982-04-01 and 1982-03-31) and they come through correctly to the server (both represent on the server as 1982-04-01 and 1982-03-31 respectively). My setup is:
GWT 2.0
Java 1.6
OSX 10.6.2
Question 2: You could always pass the 'milliseconds since January 1, 1970, 00:00:00 GMT' over the async service-which you can get using getTime() on the date object. On the server side you can then instantiate a new Date passing this value in on the constructor:
Date date = new Date(millis);
This saves fiddling around with formatters and parsers.
Dates and times are a complicated subject. The conversion can depend on the locale that the browser is running in and wether both you JVM on the server and the locales of the clients are up-to-date.
In some cases there can be differences because in some regions they switched timezones in the past.
GWT sends dates using just millis since epoch time. Since it is using Date objects, you are limited in that the Dates on the server side will be automatically modified to the servers timezone. Are you sure that you take into account the possible difference in timezones between client and server ?
David
I'm pretty certain the FTR library has some date emulation in it.
http://code.google.com/p/ftr-gwt-library
If you don't have to do client-side conversions (adapt to user's timezone) or calculations send it in a String from the server.
Never came across your specific problem though.
The possible problems soure is difference in Client/Server time zones.
We have also run into a similar problem. It was long enough ago that I do not remember the exact details but the gist of it was there were some minor differences between java.util.Date and the way dates were handled in Javascript. Our workaround was effectively the same as yours, where the actual value sent over the wire was generally a String.
Related
I want the user to enter dates, not times, just dates, using a datepicker. Doesn't seem too hard, but it's killing me.
I choose the 1st of December on the datepicker and click Save. In the Network tab on Chrome, I can see the data sent to the server has the value: 2015-11-30T22:00:00.000Z
On the server, while debugging I can see the value in the Date field is 30/11/2015 22:00:00.
This will then get stored in a Date column as 30 November 2015 and is wrong.
Where is the issue: the configuration of the angular directive, or the configuration of JSON.NET's deserialization? And how do I fix it?
Obviously quite a common question, I just needed to search a bit better.
In the end I've implemented this directive, which modifies the model used by the datepicker:
https://gist.github.com/weberste/354a3f0a9ea58e0ea0de
Basically I am trying to find a way to convert datetime of a particular timezone to other timezone while taking DST into consideration too. e.g.
What is the time in "Central Pacific Standard Time" when it is, say, 2012/9/29 9:00AM in "Tokyo Standard Time" ?
I found some solutions on the Internet to convert local machine time to other timezone.
$ToTimeZoneObj = [system.timezoneinfo]::GetSystemTimeZones() | Where-Object {$_.id -eq $ToTimeZone}
$TargetZoneTime = [system.timezoneinfo]::ConvertTime($datetime, $ToTimeZoneObj)
I am thinking if I can create a datetime object of a timezone different from the local machine, I can then use the solutions I found, or will there be other ways to do what I need?
Thanks
This solution worked well for me:
$cstzone = [System.TimeZoneInfo]::FindSystemTimeZoneById("Central Standard Time")
$csttime = [System.TimeZoneInfo]::ConvertTimeFromUtc((Get-Date).ToUniversalTime(), $cstzone)
You can then manipulate the $csttime variable just like a datetime object:
Get-Date $csttime.AddHours(-1) -f "MM\dd\yyyy HH:mm:ss"
References:
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.converttimefromutc(v=vs.110).aspx
http://technet.microsoft.com/en-us/library/ee692801.aspx
Working with TimeZones can get pretty tricky. Thank god for the updates they added in .NET 3.5 and 4.0. I worked on several time zone projects and in 2.0 is was nearly impossible without iterating the registry and building your own list of TimeZones.
Now you can get a list of TimeZones by using the TimeZoneInfo class (which you seem to be familiar with):
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx
Just beware that a system that may not be updating automatically from Windows Update could potentially have different time zones than a system that is totally up to date. Microsoft pushes out updates for time zones when needed.
I think your code seems OK. To be honest, I'm not much of a PowerShell dev (C# for me), but it seems good.
We have a really strange problem in xpages regarding dates, the Notesdocument we have contain a date field and the value is only a date, there is no time portion.
In the xpage I have specified to display the date as a date/time value. the date display correctly on the webpage but we are now getting reports from users who login at night (around midnight) and see the date as adjusted by one day. if the same people login at daytime the date is correct so this only seem to happend around midnight
I have tried to change my clock on my client to around midnight but that does not reproduce it so I assume this is a server issue.
The domino server have correct date/time and we are using the latest version of Domino
any ideas?
we encountered the same problem recently and, I believe, found a very nice solution.
system treats the pure date as a date in UTC time zone. Date value is automatically converted into server's time zone. So the question is how to prevent conversion?
this code prevents conversion:
<xp:this.converter>
<xp:convertDateTime
type="date"
ignoreUserTimeZone="true"
dateStyle="long"
timeZone="UTC">
</xp:convertDateTime>
</xp:this.converter>
pay attention at "timeZone" attribute.
The issue is related to not having the TimeZone specified in the date / time field. We ran into this just yesterday. If you don't have the TZ specified, it seems to assume UTC and will adjust accordingly. Include the time zone and your field will stop adjusting erroneously.
Perhaps it has to do with this ?
http://www-304.ibm.com/support/docview.wss?uid=swg21508734
I've seen some reports about XPages Dates and TimeZone Issues
I suspect your Domino version was 8.5.3, because there were 2 APAR, LO72278 and LO67745, on similar problems against 8.5.3. Fixpack 3 addresses them.
The root cause is that Lotus Notes allows you to save a "Date" with no time or zone and the Notes server has a default Time Zone setting to interpret these incomplete things called dates. XPages doesn't play by the same rules, and its master Java wants to know what zone you're using, and looks to the system for some clue, and generally will use midnight within some TZ to refer to a "Date". There is a whole region on Stack Overflow on the "how to store/represent a date" topic - [datetime] - since languages and DBMS each have their own approach.
Nice legacy Notes focused article about it.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/05022009100728PMAGU5MB.htm
XPages article about it
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPagesTimeZones.htm
Too bad they are not totally on the same page, I assume each release gets closer.
I want to implement timezone in my web application. I researched and saw most web app use a GMT dropdown, here is the link to that dropdown http://www.attackwork.com/BlogEntry/6/Time-Zone-Dropdown-Select-List/Default.aspx
Then I saw this article suggesting UTC is the way to go when it comes to implement timezone. https://web.archive.org/web/20210513223048/http://aspnet.4guysfromrolla.com/articles/081507-1.aspx Basically it's saying don't use DateTime.Now instead use DateTime.UtcNow
My questions are,
Is there a dropdown of the timezones in UTC, like the first link I showed there is one on GMT?
Should I really use UTC or GMT?
.NET 3.5 provides the TimeZoneInfo class which should make it relatively simple for you to populate a dropdown with time zones. GMT came before UTC and UTC was officially instituted on January 1, 1972. See this link for more information. For today's purposes, the two are pretty much synonymous, though they have different historical origins. Use whichever looks and functions better for your purposes.
I'm not sure if this is what you intended to ask, but in your database you should always store timestamps in UTC/GMT (as noted by others they mean essentially the same thing). For each user of your web app, store the time zone preference.
Then whenever you display the timestamp for something to a user, convert the UTC time in the database to the user's timezone.
GMT (Greenwich Mean Time) is the same as UTC (Universal Coordinated Time). This isn't an either/or choice - use it :)
Use Localization settings, functions and features anywhere possible.
If you aren't running against SQL Server 2008 or don't want to abstract timezone management to the database, you should store all times as UTC/GMT and apply the timezone difference based off the user's profile setting, so that users from all around the world can see timestamps on events in their local time.
The distinction between UTC and GMT is probably too fine to bother with in your code. However, it's probably a good idea to always save and process times internally with zero timezone offset, and deal with it as a presentation concern.
It's also possible to use JavaScript to determine the user's probable timezone: examine the timezone offsets for some pair of Date objects reasonably close to the solstices (even January 1 and July 1 makes a suitable approximation) to obtain a coarse timezone identification. Feel free to use this information to determine a default timezone, but do allow it to be changed by the user: JavaScript doesn't provide sufficient detail to select the exact timezone with national and regional historical shifts, and it may not be enabled by the user anyway.
I have an asp.net webservice with a parameter of type datetime. I have noticed asp.net seems to offset the date based on the clients timezone.
I need to disable this functionality. I simply want to pass a date (i.e. 3/15/2009) to the webservice from javascript without any timezone context.
Is my only option to change the parameter type to string then convert it server side, or is there some way to disable the deserializer from offsetting my date param ?
I'd use a string.
It kind of makes sense - a DateTime is really a "point in time", so when two clients are talking about the same DateTime, they're talking about the same INSTANT. So saying "the meteor will hit earth in 5 minutes", should adjust itself to the timezone.
You could use a UTC date instead: http://www.java2s.com/Code/JavaScript/Date-Time/GetUTCDate.htm
I had exactly this "problem" and when I thought it through, I realized that the way it worked was indeed correct, at least for my scenario. In my case, I was receiving an activeFrom and activeTo date. These can only be dates (no time part) when I actually submit these values to the processor. Our web server is in Eastern Time. I happened to be testing from a client in Central Time. My test case was failing because the value stored in the database did not match what I sent (EG 04/01/2009 01:00 vs 04/01/2009 00:00).
I thought about just stripping off the time part. This seemed OK until I considered a request coming in from a time zone east of Eastern (which would happen becuase we have clients in Thailand). I was upset because the resulting date would be one day before the date sent in the request. Then I realized, that's exactly the date I want to use.
Hopefully your scenario will work out as serendipitously as mine.