jsr310

It seems that the new java.time API offers everything from java.util.Date and much more. Is there any reason to use java.util.Date when the newer java.time API is there since Java 8? Should java.util.Date and java.util.Calendar be avoided completely? Short answer: The new API java.time is way better than the old world with java.util.Date and java.util.Calendar . So yes, the new API should be preferred in new code. For a quick overview: Once I had written a comparison of features in table form for various date-time-libraries. There is almost no feature which java.time is missing but exists in

I came across https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941.html . 1) I am currently migrating Java Calendar to joda-time. I was wondering, should I use threeten instead of joda-time? Is threeten production ready? 2) Can threeten library and joda-time libraries exist together in a same application? As I am using some 3rd parties libraries, which is using joda-time library too. 3) Will joda-time become an abandon project since there is threeten? Official reply: As of January 2011, ThreeTen is still what I'd classify as an Alpha. That means that I am changing method names, classes

I'm using the library described the Jackson Datatype JSR310 page but I'm still having difficulty getting it to work. I have configured the following bean: @Bean @Primary public ObjectMapper objectMapper() { ObjectMapper mapper = new ObjectMapper(); mapper.registerModule(new JSR310Module()); return mapper; } When I call my REST API the date format output is yyyy-MM-dd'T'HH:ss.SSSSSS , e.g. 2015-04-11T00:10:38.905847 . This gets handled by my AngularJS code just fine. When I want to submit something to the REST API the date is posted as yyyy-MM-dd'T'HH:mm:ss.SSS'Z' , e.g. 2015-04-09T08:30:00

I'm using ThreeTen-Backport library for my Android project (because java.time is not yet implemented in android development). When I write LocalDate today=LocalDate.now(); or LocalTime time=LocalTime.now(); I get the following exception: Caused by: org.threeten.bp.zone.ZoneRulesException: No time-zone data files registered at org.threeten.bp.zone.ZoneRulesProvider.getProvider(ZoneRulesProvider.java:176) at org.threeten.bp.zone.ZoneRulesProvider.getRules(ZoneRulesProvider.java:133) at org.threeten.bp.ZoneRegion.ofId(ZoneRegion.java:143) at org.threeten.bp.ZoneId.of(ZoneId.java:357) at org

jsr-310 has a handy class DateTimeFormatters which allows you to construct a DateTimeFormatter . I particularly like the pattern(String) method - see javadoc However, I hit a problem whereby this is case sensitive -- e.g. DateTimeFormatters.pattern("dd-MMM-yyyy"); matches with "01-Jan-2012", but not with "01-JAN-2012" or "01-jan-2012". One approach would be to break the string down and parse components, or another would be to use Regex to replace the case-insensitive strings with the case-sensitive string. But it feels like there ought to be an easier way... amaidment And there is... according