I have seen countless forum posts complaining of issues in GWT when handling dates. I am still very unclear as to what is "wrong" with the date handling, what special considerations need to be made, and when/where/why methods like Date.setMinutes(int minutes) should not be used.
Does anybody have feedback?
Way back in the beginning of Java (i.e., Java 1.0), the date/time api largely (solely?) consisted of the Date class. The Java folks were aware that it lacked robustness, so they added the Calendar class in Java 1.1 and tried to change the Date class into a value object by deprecating most of it. Unfortunately, the Calendar class itself wasn't very well thought-out (see here) and we're stuck with what many consider to be a monstrosity.
Bringing us up to today, GWT supports Date because, well... how can you live without dates?, but doesn't support Calendar/GregorianCalendar/TimeZone because it's so ugly and surely there has to be a better answer. Sadly, no one's thought of it in over 3 years as Calendar support was requested way back in January of 2007 and marked as planned by April 2008.
In short, go ahead and use the the deprecated Date methods in your GWT code, if that will work for what you need to do.
EDIT: GWT's CalendarUtil class might also come in handy.
Related
Are there breaking changes in Moment from version 2.1.0 to 2.13.0?
I just inherited a code base that is using the older version and want to know if there will be problems upgrading to 2.13 from 2.1. Unfortunately there are no JavaScript unit tests for our web app.
I can say that in general, moment follows SemVer, so there are no breaking API changes.
However you may find some behavioral changes, as various bugs have been fixed over the years. Some consider it a "breaking change" when they depended on a particular bug being exhibited and later the bug was fixed, or when a function was improved to be more semantically correct.
As an example, the string returned by moment.utc().format() used to include an offset of +00:00, and it now returns Z. This more closely conforms to the ISO8601 and RFC3339 specifications, so the previous implementation was considered a bug, and it has since been resolved. Most people were fine with this change, as either form should be accepted by all modern parsers, but a few folks complained that this broke their code because they were manually parsing the results via string manipulation, and expecting a numeric value for the offset. We don't consider this a breaking change because the API didn't change, and the resulting string was compliant with the spec both before and after the change - it's just more accurate semantically now.
There are a few miscellaneous other changes like this, and they are all referenced in the changelog. If you edit your question to show which features of moment you are using, then I might be able to provide more details.
I had a hard time finding anything on this critical problem so I decide to post this to help users running into the same issue.
The Chrome embedded Flash Player (Pepper) has a bug concerning date timezoneOffset that leads to some unpredictable behaviors when your application deals with dates.
As we provide a commercial Flex calendar component (KC-Calendar), this issue is critical for our clients and for their applications.
The issue details can be found here: http://code.google.com/p/chromium/issues/detail?id=154060
(please vote)
Waiting for a fix, if someone has a workaround, it could be really helpful.
Thanks in advance!
We've dealt with such issues before, and honestly--rather than playing around with trying to serialize Dates--IMO the best solution (unless you WANT auto timezone conversion) is to simply pass date data types as strings. We do this cleanly using Java and ActionScript getters/setters which (correctly) set the serialized "date" objects in our DTO by parsing the un-adjusted date strings.
Ex. when you set a Date object's value, in the setter you convert Date to String & set a String field for that date. In the getter you get the String value for that date and parse it, returning a new Date object. Do this on server and client side.
The only minor caveat, obviously, is that you need to ensure the Flex & server side String-to-Date/Date-To-String functions use the same date format. Just put a nice comment explaining this (so nobody screws with it) next to your serialization date parsers/formatters and you're fine.
I expect this issue will probably go away once an HTML5-based Flex compiler is released (it's really just a Flash feature which isn't the desired behavior in our cases).
This problem makes me really sad. I'm working with a pretty archaic web application with an eclectic mix of programming languages. Previously, it stored any and all datetimes in a Datetime field in our MySQL database. Until now, everything has been done in server time, which happens to be US/Pacific. I was tasked with adding "Timezone functionality" to the application. I have been pretty successful with converting most of the application.
My only remaining problems are the use of ColdFusion specific datetime functions. There appears to be many lines of code that use some of these functions. My ideal situation would be to be able to adjust the timezone on my Application.cfm page and not need to worry about the timezone for any of these functions. I've done quite a bit of searching and I can't seem to find anything. Any help would be awesome! Please let me know if I can provide any more details.
see: How to handle timezones in CFML?
Over the past three weeks, I have lost at least 120 man hours because of some lesser known functionality in ActionScript 3. One of the problems was that, with Internet Explorer, if there are too many messages sent through LocalConnections, it will slow the messages sent through, but in the standalone player and in Firefox, this threshold is significantly higher. Another was that the static values of a class are instantiated even if the member itself is not being used:
import path.to.FooClass;
private function thisIsNeverCalledButItEnsuresThatFooClassIsImported():void
{
var f:FooClass = new FooClass();
}
Since FooClass had a static reference to a Singleton, that Singleton was instantiated so when I loaded a Module which used that Singleton, it would bind to values in an unpredictable way.
Additional cases where things behave in an unexpected way:
MovieClip.addFrameScript
flash.trace.Trace as a class
int is a faster incrementer class, Number is faster for mathematics, and uint is incredibly slow.
PrintDataGrid, if it has only one page, needs to have an empty value appended to the end of its dataProvider
If you use try...catch around two LocalConnections and connect them to the same channel, you will force garbage collection without needing System.gc
So here's the question (and I'm sorry for omitting this in the original post), is there any consolidated documentation for this type of behavior anywhere? Is there any (even non-Adobe) documentation on these issues (websites, forums, books, ANYTHING)? I know that these things are definitely easy enough TO document, but has anyone done so?
If not, am I missing anything? Are there other issues which I should know about?
This kind of useful information is very often not "centralized". Moreover, what you are looking for is something related to the experience of the programmer (more than to official docs).
FYI, there are two other methods for ensuring a class is included.
#1 - This syntax is actually used in the Flex source code:
import path.to.FooClass; FooClass; // note double reference
public class References
{
// No references needed in this class
}
#2 - Use the includes command line argument
-includes path.to.FooClass
You can always submit your experience using the "feedback" section in the help. Unfortunately, this is less obvious than the link that used to be at the bottom of each page in the older help files (which also served the useful function of opening a browser window with the web version of that help page).
Adobe says that it incorporates the comments from previous versions of the help into new versions, but my own observation suggests that there are instances where it does not happen. However, that and the appropriate cookbook are still the best avenue for those who believe that this kind of information should be centralized.
Note that the whole purpose behind modules is to avoid compiling code multiple times, so importing FooClass kind of defeated the purpose. The problems you had in this instance are just one of the many that happen if you use Singletons, and it's unfortunate that the first official Framework, Cairngorm, encouraged their widespread use. Check out http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ .
I'm building a new ASP.NET web application based on a legacy one (Classic ASP). The people, who build this code 4, 5 years ago, used a lot of VBScript functions like DateDiff.
I'm currently working on a simulator that does a lot of calculations with dates. And I'm getting a annoying difference between these dates because I don't have a easily manner to get the difference between months in c# like they did in VB 6.
So, I choose the path of using the DateAndTime.DateDiff from Microsoft.VisualBasic namespace on my ASP.NET web application.
You guys know if there are some implications on that? I'm a little concerned with this approach.
Cheers,
The only implication is that you're adding another assembly to your deployment, and using functionality that many C# developers (other people that might need to maintain your code) are not aware of. But personally I don't think there's much wrong with it. The MSDN Library documentation is typically good, and you can also add a few comments if you want to explain why your using it.
Edit: I also want to note that Microsoft.VisualBasic was implemented from scratch for .NET. It does not contain ancient code.
One possibility is to use the TimeSpan as Itay indicated, but divide by 30.4375 (the average days per month), ignoring fractional months. This is close enough for things I'm currently working on, but may not be accurate enough based on your needs. For instance, The difference between February 1 and March 1 would be 0, which (based on a 30.4375 day month definition) is correct; it may not be correct for your particular purposes, however.
It's good thing you are concerned with that, because you should not use any of of the classed in the VisualBasic namespace.
The .net library offer a much better solution called TimeSpan, use it in the following way: (dt1, and dt2 are DateTimes)
TimeSpan ts = dt2 - dt1; //Or ts = dt1.Subtract(dt2)
As far as i would like to help, I really think a quick glance at the intellisence will tell you the rest (just write this in Visual Studio, and add ts.)
EDIT for real month counting: (y2 - y1) * 12 + m2 - m1, what the big deal?