javax.time (JSR-310) emulation

[dankurka]

Originally reported on Google Code with ID 603

GWT Release: 1.3

Detailed description:
This is a feature request to include emulation for the java.util.Calendar
abstract class, and an implementation like GregorianCalendar. This would
make dealing with dates much better in GWT. java.text.SimpleDateFormat
would be nice too, but not essential.

Workaround if you have one:
Dealing with dates on the client side of GWT is currently fairly messy, and
involves using all of the deprecated methods on the java.util.Date class.

Links to the relevant GWT Developer Forum posts:
http://groups.google.com/group/Google-Web-Toolkit/browse_frm/thread/220837cbfce5e4b0/118901d39dd2b10b?lnk=gst&q=java.util.Calendar&rnum=2#118901d39dd2b10b
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/f9136940ddd494e9/e53fc30c7a2e42f9?lnk=gst&q=date&rnum=1#e53fc30c7a2e42f9

Reported by rustyshelf on 2007-01-17 06:13:26

[dankurka]

I love the GWT guys too, but this was raised over 4 years ago, not seconds ago :)

Reported by rustyshelf on 2011-07-31 00:20:27

[dankurka]

Obviously they can't implement the whole Java standard library on the client side. The
way Java implements Calendars is far from lightweight. So I don't see why it should
be at all surprising that they would be reluctant to bring this elephant into GWT.
That's why I wouldn't expect a quick resolution to this bug. If it were me, I'd probably
just mark it "won't fix". 

Reported by andy16666 on 2011-07-31 00:27:34

[dankurka]

The calendar emulation in the ftr library mentioned above works pretty well (I'm one
of the contributors he mentioned). It's not a complete replacement since it doesn't
do timezones, internationalization, different calendar types, etc., but it handles
the most common simple use cases and is direct drop in emulation. Give it a try. 

Reported by david@sogeeky.net on 2011-07-31 00:33:55

[dankurka]

Agree. We than should open a new issue called "provide date time api". And another one
"provide week numbers to date time api". And then we could open a new one...

Or we just stick to this one, as long as we all know that java.util.Calendar won't
be it.

Reported by pgtaboada on 2011-07-31 00:34:29

[dankurka]

Oh, and btw, what are you guys using? Any one of those joda time gwt projects? I am
doing my calendar stuff in the backend, and this is a real pain.

Reported by pgtaboada on 2011-07-31 00:45:23

[dankurka]

ISO 8601 week numbers is:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4009
http://en.wikipedia.org/wiki/ISO_8601#Week_dates

Reported by jdougla@basis.com on 2011-07-31 00:46:59

[dankurka]

Thanks for pointing out.
Maybe it would really be better to merge all the date time issues into one. I have
starred the week numbers issue to, and the one working on it is doing so since Sep,
15th 2009. 

An official statement from the gwt dev team would be nice/ refreshing...

Reported by pgtaboada on 2011-07-31 00:51:12

[dankurka]

We've been using gwt-time in the frontend and joda-time in the backend for quite a while
now and we're really happy with this solution! The only pain is transferring date/time
objects between back- and frontend as gwt- and joda-time are incompatible. To accomplish
the conversion reliably we wrote DTOs (eg. LocalDateDTO), (consisting of a single long
value) along with conversion methods (eg. LocalDateDTO toDTO(LocalDate localDate),
...).

My preferred solution for this issue is to support JSR-310 [1] in GWT once Java 8 is
final as it will be the new standard date/time API for Java and it will be very similar
to joda-/gwt-time. Until then I recommend using these two libraries.

[1] http://jcp.org/en/jsr/detail?id=310

Reported by wuertinger.michael on 2011-07-31 10:40:18

[dankurka]

My +1 vote for joda-time library support in gwt. We maintain our own DateUtil class
that does various things using DateTimeFormat. 

Reported by rakeshw on 2011-08-01 05:43:32

[dankurka]

Reported by rjrjr@google.com on 2011-10-04 23:46:10

• Status changed: PatchesWelcome

[dankurka]

Calendar is pretty much a non-starter. And I don't think a complete Joda emulation is
practical. 

Set to patches welcome because the GWT team has no immediate plans to do anything about
this. Also, there's no reason such a project would have to be part of GWT proper (though
it would be nice to have a non-deprecated way to do this kind of thing :-/ )

Reported by rjrjr@google.com on 2011-10-04 23:48:14

[dankurka]

Back when I was using GWT there actually was a pretty good reason for that. You see,
our project had tons of domain classes (persistable entities too) that used Calendar
for storing dates so we had to hack a calendar class of our own (storing only data
with no functionality) *just to avoid creating tons of DTOs*.

Reported by mirceade on 2011-10-05 07:26:59

[dankurka]

Reported by rjrjr@google.com on 2011-10-06 23:56:39

• Labels removed: Milestone-Planned

[dankurka]

I see the label changed to "Milestone-Planned". So what exactly is planned on this?
Calendar OR Joda OR combination? Curious!

Reported by rakeshw on 2011-10-07 23:51:02

[dankurka]

Ryan actually deleted the label "Milestone-Planned". That's why it has that little minus
sign there in front ;)

Reported by rocky303 on 2011-10-08 09:50:23

[dankurka]

Actually, the Milestone-Planned label has been *removed* (it was added in comment #9)

My (very own) opinion is that we should just wait for JSR 310 http://threeten.sourceforge.net/
, or use JodaTime.

Reported by t.broyer on 2011-10-08 09:53:18

[dankurka]

Did anyone have a look at it? Actually, my main concern is that, like any one of the
gwt-jodatime project around, any time lib lib not specifically designed for gwt will
drastically increase the size of any gwt app using it. 

I like the idea of the lightweight collection proposed in the wike, and I would prefer
a lightweight solution here too. 

Reported by pgtaboada on 2011-10-09 21:00:52

[dankurka]

Issue 7173 has been merged into this issue.

Reported by t.broyer on 2012-02-06 09:16:59

[dankurka]

I this laid around for so long I think this issues should be scheduled as soon as JSR-310
is accepted.

Reported by walec5 on 2012-03-28 15:51:52

[dankurka]

client side jaxb and xjc models are fully blocked on Duration and XMLGregorianCalendar
with painful text replacement as a workaround.  

Reported by northrup.james on 2012-09-24 22:43:34

[dankurka]

Many thanks for sharing:)

Reported by gemmapiedad1 on 2013-01-06 08:58:27

[dankurka]

Java time api is out for early access
http://www.infoq.com/news/2013/02/java-time-api-jdk-8

Reported by wokier on 2013-02-11 09:33:43

[dankurka]

http://code.google.com/p/google-web-toolkit/issues/listcontreraznt&automated at work

Reported by VictorhsAliascontreraz on 2013-05-16 16:32:14

[dankurka]

Issue 8486 has been merged into this issue.

Reported by t.broyer on 2013-12-10 09:22:58

[dankurka]

Re-purposing for JSR-310 support.

Reported by t.broyer on 2013-12-10 09:23:58

[dankurka]

So once again here:
https://github.com/m-m-m/mmm/issues/83

Before any further steps I would like to get some feedback if my overall strategy (read
issue above) fits with what other GWT users would expect. Please discuss here:
https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/qLQPU2n6Qpw

Reported by joerg.hohwiller on 2013-12-31 00:57:45

[dankurka]

I don't know enough about JSR-310 to render any intelligent comments on your approach,
however, I do support moving forward with JSR-310 instead of Date and/or Calendar support.
FWIW, I've rolled my own ISO 8601 timestamp based system with timezone support by using
bits from the GXT 2 library, the IANA TZ db, string parsing and coercing things through
java.util.Date as needed to make it all work. A recent review of JSR-310 shows it's
API approach to be very similar to mine, so I am looking forward to switching to it.

If my hack-arounds sound interesting and could be of use or inspiration to you, let
me know and I'll see about sharing them. 

Reported by david@sogeeky.net on 2013-12-31 15:57:53

[dankurka]

Can we have class which at least returns Year,Month, Day of Month etc values. This I
need for comparison purposed to determine date versus date time values.

Reported by appe.raja on 2014-02-19 08:40:09

[dankurka]

I guess GWT team will invest their time into JSR-310 emulation instead of giving half
baked solutions. Meanwhile it is expected to roll your own solutions for all your Calendar
needs.

Reported by rocky303 on 2014-02-19 09:12:21

[dankurka]

By far the most voted issue, and we are still guessing. Not good.

Reported by pgtaboada on 2014-02-19 09:14:12

[dankurka]

I got feedback from Stephen Colebourne that we can use the BSD-licensed code from his
backport and fork it to create a GWT portation.

I would suggest to create a new module instead of directly putting this into JRE emul
of gwt-user. This way it would be easier to handle this with the overall roadmap and
we would already prepare for the GWT modularization. Any thoughts on this?

Reported by joerg.hohwiller on 2014-04-26 10:11:07

[dankurka]

> Can we have class which at least returns Year,Month, Day of Month etc values. 
> This I need for comparison purposed to determine date versus date time values.
GWT from the start properly supports java.util.Date. While this class is very ugly
it provides what you request here. Write a small helper or wrapper around it to make
it eaiser to handle (years and month) and get around the deprecations in your regular
usage.

Reported by joerg.hohwiller on 2014-04-26 10:30:38

[dankurka]

To start with the java.time emulation now, I would keep the code at Java 1.7 syntax
to make it easy to test. Java 1.8 support for GWT (e.g. default methods in interfaces)
will still take some time as I assume. When GWT 1.8 support is our, we can upgrade
the java.time emulation code.

Reported by joerg.hohwiller on 2014-04-26 10:32:55

[dankurka]

Making it a new GWT module seems fine, as you probably need some GWT specific classes
on the client side anyways. That would be kind of similar to the Bean Validation approach.

Also I don't think there will be a lot of situations where you actually want to use
Java 8 syntax in emulation code so starting with Java 7 syntax seems totally fine to
me.

Do you know if https://github.com/ThreeTen/threetenbp already matches final JDK 8?

Reported by jens.nehlmeier on 2014-04-26 14:33:49

[dankurka]

Integrating java.time into GWT's Emul would have the benefit of allowing the java.util.Date#toInstant()
to be emulated.
But pending Java 8 support (with emulation!), there should be no problem developing
it as an independent library (which could later be merged into / used as the basis
for the emul-jdk8 JAR)

Reported by t.broyer on 2014-04-28 01:47:29

[dankurka]

would somebody be willing to guide someone through the patch submission process ? There
is this project that has a working implementation of jsr-310: https://github.com/m-m-m/gwt-time

Reported by diaz.salvador on 2015-01-19 10:37:54

[dankurka]

The patch submission process is not the problem. The problem is that my retrofitting
into GWT will need a lot of rework before being acceptable for the GWT project. See
it as a starting point for people willing to invest some time and energy to finally
make it happen.

Reported by joerg.hohwiller on 2015-01-20 21:17:27

[dankurka]

I am willing to spend the time and energy to make it happen, I just don't known where
to start.

Reported by diaz.salvador on 2015-01-21 08:18:58

[dankurka]

Great. You should be able to run a simple Main method using LocalDateTime, Instant,
etc. and printing some results. You should also be able to create a small GWT APP with
an enty point doing the same and printing results into HTML. Therefore you need to
include my gwt-time code as lib and also import its gwt.xml. If you have GWT experience
you should be able to get there. Then stepwise add complexity to your APP and discover
unsupported spots...

Reported by joerg.hohwiller on 2015-01-27 22:09:53

[joelhandwell]

@salvadordiaz any update?

[keinhaar]

Users who need these classes should use https://github.com/foal/gwt-time