Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: None
    • Labels:
      None

      Description

      Apologies if I have missed an existing issue but I'm trying to determine how the convertDateTime converters will be aligned to support Java 8 Date and Time API in JSF 2.3

        Issue Links

          Activity

          Hide
          codylerum added a comment -

          I meant to do this as a SPEC issue. Can it be moved?

          Show
          codylerum added a comment - I meant to do this as a SPEC issue. Can it be moved?
          Hide
          Manfred Riem added a comment -

          Done

          Show
          Manfred Riem added a comment - Done
          Hide
          Ed Burns added a comment -

          Yes, this is a must for JSF 2.3.

          EG member Josh Juneau wrote a blog post about it, but to actually get it in the spec we need a lot more work: < http://www.javacodegeeks.com/2015/06/utilizing-the-java-8-date-time-api-with-jsf-and-java-ee-7.html >.

          Show
          Ed Burns added a comment - Yes, this is a must for JSF 2.3. EG member Josh Juneau wrote a blog post about it, but to actually get it in the spec we need a lot more work: < http://www.javacodegeeks.com/2015/06/utilizing-the-java-8-date-time-api-with-jsf-and-java-ee-7.html >.
          Hide
          Ed Burns added a comment -

          Some questions about putting this in the spec.

          1. What do we need to say in section 3.3.3 Standard Converter Implementations?

          2. Which of java.time.

          {LocalDate,LocaleTime,LocalDateTime}

          do we want to support? All of them I'd think, but how does this square with the JSF conversion model which seems to favor the combined "DateTime" concept.

          3. Perhaps we should create a new converter along side DateTimeConverter, say JavaTimeDateTimeConverter and trick it out with lots of attributes as the current DateTimeConverter does?

          Show
          Ed Burns added a comment - Some questions about putting this in the spec. 1. What do we need to say in section 3.3.3 Standard Converter Implementations? 2. Which of java.time. {LocalDate,LocaleTime,LocalDateTime} do we want to support? All of them I'd think, but how does this square with the JSF conversion model which seems to favor the combined "DateTime" concept. 3. Perhaps we should create a new converter along side DateTimeConverter, say JavaTimeDateTimeConverter and trick it out with lots of attributes as the current DateTimeConverter does?
          Hide
          javajuneau added a comment -

          Actively working on prototype of LocalDateTime conversion.

          Creating a new converter, as suggested by Ed Burns, and utilizing the "type" attribute of the convertDateTime tag to indicate the conversion of "localDateTime".

          Show
          javajuneau added a comment - Actively working on prototype of LocalDateTime conversion. Creating a new converter, as suggested by Ed Burns, and utilizing the "type" attribute of the convertDateTime tag to indicate the conversion of "localDateTime".
          Hide
          Ed Burns added a comment -

          Josh! I created a topic branch for this, it is JAVASERVERFACES-4070. Please pull that branch and work from there.

          I've made some good progress already.

          Show
          Ed Burns added a comment - Josh! I created a topic branch for this, it is JAVASERVERFACES-4070 . Please pull that branch and work from there. I've made some good progress already.
          Hide
          javajuneau added a comment -

          Thanks Ed, will do! I appreciate it.

          Show
          javajuneau added a comment - Thanks Ed, will do! I appreciate it.

            People

            • Assignee:
              Ed Burns
              Reporter:
              codylerum
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 30 minutes
                30m