Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8143413

add toEpochSecond methods for efficient access

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b100

      Description

      To efficiently get an epochSecond value:

      - add 'toEpochSecond(ZoneOffset) ' methods to 'LocalDate' and 'LocalTime'.
      - add 'toEpochSecond() ' method to 'OffsetTime'.

      The method on 'LocalDate' would be defined to set the time part to midnight (safe as ZoneOffset, not ZoneId)
      The methods on the time classes would be defined to set the date part to 1970-01-01.

        Issue Links

          Activity

          rriggs Roger Riggs created issue -
          rriggs Roger Riggs made changes -
          Field Original Value New Value
          Link This issue relates to JDK-8030864 [ JDK-8030864 ]
          rriggs Roger Riggs made changes -
          Description - add 'toEpochSecond(ZoneOffset) ' methods to 'LocalDate' and 'LocalTime'.
          - add 'toEpochSecond() ' method to 'OffsetTime'.

          The method on 'LocalDate' would be defined to set the time part to midnight (safe as ZoneOffset, not ZoneId)
          The methods on the time classes would be defined to set the date part to 1970-01-01.
          The complement of an efficient getDateTimeMillis:

          - add 'toEpochSecond(ZoneOffset) ' methods to 'LocalDate' and 'LocalTime'.
          - add 'toEpochSecond() ' method to 'OffsetTime'.

          The method on 'LocalDate' would be defined to set the time part to midnight (safe as ZoneOffset, not ZoneId)
          The methods on the time classes would be defined to set the date part to 1970-01-01.
          rriggs Roger Riggs made changes -
          Issue Type Bug [ 1 ] Enhancement [ 7 ]
          rriggs Roger Riggs made changes -
          Status New [ 10000 ] Open [ 1 ]
          rriggs Roger Riggs made changes -
          Assignee Roger Riggs [ rriggs ] Nadeesh Tv [ ntv ]
          rriggs Roger Riggs made changes -
          Description The complement of an efficient getDateTimeMillis:

          - add 'toEpochSecond(ZoneOffset) ' methods to 'LocalDate' and 'LocalTime'.
          - add 'toEpochSecond() ' method to 'OffsetTime'.

          The method on 'LocalDate' would be defined to set the time part to midnight (safe as ZoneOffset, not ZoneId)
          The methods on the time classes would be defined to set the date part to 1970-01-01.
          To efficiently get an epochSecond value:

          - add 'toEpochSecond(ZoneOffset) ' methods to 'LocalDate' and 'LocalTime'.
          - add 'toEpochSecond() ' method to 'OffsetTime'.

          The method on 'LocalDate' would be defined to set the time part to midnight (safe as ZoneOffset, not ZoneId)
          The methods on the time classes would be defined to set the date part to 1970-01-01.
          Hide
          ntv Nadeesh Tv (Inactive) added a comment -
          @Stephen, @Roger - Is there any particular reason for not adding 'toEpochSecond()' method to OffsetDateTime, LocalDateTime, ZonedDateTime?
          Show
          ntv Nadeesh Tv (Inactive) added a comment - @Stephen, @Roger - Is there any particular reason for not adding 'toEpochSecond()' method to OffsetDateTime, LocalDateTime, ZonedDateTime?
          ntv Nadeesh Tv (Inactive) made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          Hide
          ntv Nadeesh Tv (Inactive) added a comment - - edited
          ZonedDateTime implements ChronoZonedDateTime and LocalDateTime implements ChronoLocalDateTime.
          Both ChronoZonedDateTime and ChronoLocalDateTime alreday have toEpochSecond().

          Similarly OffsetDateTime also have toEpochSecond().

          Hence not required to implement 'toEpochSecond()' method for OffsetDateTime, LocalDateTime, ZonedDateTime
          Show
          ntv Nadeesh Tv (Inactive) added a comment - - edited ZonedDateTime implements ChronoZonedDateTime and LocalDateTime implements ChronoLocalDateTime. Both ChronoZonedDateTime and ChronoLocalDateTime alreday have toEpochSecond(). Similarly OffsetDateTime also have toEpochSecond(). Hence not required to implement 'toEpochSecond()' method for OffsetDateTime, LocalDateTime, ZonedDateTime
          Hide
          ntv Nadeesh Tv (Inactive) added a comment -
          @Stephen, Roger
          I have a confusion about the access modifier of 'toEpochSecond()' .
          I understood why toEpochSecond in ChronoZonedDateTime or ChronoLocalDateTime is 'default'.
          If I made access modifier of toEpochSecond () in LocalDate, LocalTime public , does not it create a inconsistency?
          Because LocaldateTIme, ZonedDateTime does not have any public toEpochSecond() but LocalDate etc. will have.
          Show
          ntv Nadeesh Tv (Inactive) added a comment - @Stephen, Roger I have a confusion about the access modifier of 'toEpochSecond()' . I understood why toEpochSecond in ChronoZonedDateTime or ChronoLocalDateTime is 'default'. If I made access modifier of toEpochSecond () in LocalDate, LocalTime public , does not it create a inconsistency? Because LocaldateTIme, ZonedDateTime does not have any public toEpochSecond() but LocalDate etc. will have.
          Hide
          scolebourne Stephen Colebourne added a comment -
          All methods on interfaces are 'public'. Unfortunately, Oracle chose a coding standard where the 'public' keyword is not specified. The 'default' keyword has an entirely different meaning, and I'd suggest researching it if you are unclear what it means on an interface.

          The new methods should all be public.
          Show
          scolebourne Stephen Colebourne added a comment - All methods on interfaces are 'public'. Unfortunately, Oracle chose a coding standard where the 'public' keyword is not specified. The 'default' keyword has an entirely different meaning, and I'd suggest researching it if you are unclear what it means on an interface. The new methods should all be public.
          Hide
          ntv Nadeesh Tv (Inactive) added a comment -
          Sorry. I got confused myself with the 'default access modifier '
          Show
          ntv Nadeesh Tv (Inactive) added a comment - Sorry. I got confused myself with the 'default access modifier '
          Show
          ntv Nadeesh Tv (Inactive) added a comment - http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/037024.html
          Hide
          rriggs Roger Riggs added a comment - - edited
          As proposed, the added methods assume the missing values for the time or date to compute a epoch second value.
          After some discussion it was proposed to add arguments to the functions to provide the missing values.

          The methods are:
          LocalDate::public long toEpochSeconds(LocalTime time, ZoneOffset offset)
          LocalTime::public long toEpochSeconds(LocalDate date, ZoneOffset offset)
          OffsetTime::public long toEpochSeconds(LocalDate date)

          Adding a constant will help provide a common value for the EPOCH:
          LocalDate:: public static final LocalDate EPOCH = LocalDate.of(0, 0, 0);
          Show
          rriggs Roger Riggs added a comment - - edited As proposed, the added methods assume the missing values for the time or date to compute a epoch second value. After some discussion it was proposed to add arguments to the functions to provide the missing values. The methods are: LocalDate::public long toEpochSeconds(LocalTime time, ZoneOffset offset) LocalTime::public long toEpochSeconds(LocalDate date, ZoneOffset offset) OffsetTime::public long toEpochSeconds(LocalDate date) Adding a constant will help provide a common value for the EPOCH: LocalDate:: public static final LocalDate EPOCH = LocalDate.of(0, 0, 0);
          Hide
          ntv Nadeesh Tv (Inactive) added a comment -
          Hi Roger,Stephen,
          Could you please clarify following queries

          1. If we can pass LocalTime as an argument to LocalDate::public long toEpochSeconds(LocalTime time, ZoneOffset offset) then
                     can we name the method as toEpochSeconds()? (Since epoch-seconds are measured from the MIDNIGHT of 1970-01-01)?
          2. Similarly for LocalTime::public long toEpochSeconds(LocalDate date, ZoneOffset offset) (since we could pass any LocalDate)
          Show
          ntv Nadeesh Tv (Inactive) added a comment - Hi Roger,Stephen, Could you please clarify following queries 1. If we can pass LocalTime as an argument to LocalDate::public long toEpochSeconds(LocalTime time, ZoneOffset offset) then            can we name the method as toEpochSeconds()? (Since epoch-seconds are measured from the MIDNIGHT of 1970-01-01)? 2. Similarly for LocalTime::public long toEpochSeconds(LocalDate date, ZoneOffset offset) (since we could pass any LocalDate)
          Hide
          scolebourne Stephen Colebourne added a comment -
          The method name would be `toEpochSecond()` to match that on `LocalDateTime`. (The singular is used for all temporal fields, the plural is used for all temporal units. Since epoch-scond is a field, it is singular).
          Show
          scolebourne Stephen Colebourne added a comment - The method name would be `toEpochSecond()` to match that on `LocalDateTime`. (The singular is used for all temporal fields, the plural is used for all temporal units. Since epoch-scond is a field, it is singular).
          Hide
          rriggs Roger Riggs added a comment -
          Epoch seconds are UTC, so the offset argument is present to shift the reference point from 'local' to UTC time.
          Show
          rriggs Roger Riggs added a comment - Epoch seconds are UTC, so the offset argument is present to shift the reference point from 'local' to UTC time.
          Show
          ntv Nadeesh Tv (Inactive) added a comment - http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037717.html
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0a642db657b
          User: rriggs
          Date: 2015-12-23 18:53:10 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0a642db657b User: rriggs Date: 2015-12-23 18:53:10 +0000
          hgupdate HG Updates made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolved In Build team [ 17324 ]
          Understanding Fix Understood [ 10001 ]
          Fix Version/s 9 [ 14949 ]
          Resolution Fixed [ 1 ]
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d0a642db657b
          User: lana
          Date: 2016-01-06 20:14:31 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d0a642db657b User: lana Date: 2016-01-06 20:14:31 +0000
          hgupdate HG Updates made changes -
          Resolved In Build team [ 17324 ] master [ 18256 ]
          hgupdate HG Updates made changes -
          Resolved In Build master [ 18256 ] b100 [ 17728 ]
          iris Iris Clark made changes -
          Labels jsr379-annex2-tbd
          iris Iris Clark made changes -
          Labels jsr379-annex2-tbd jsr379-annex1
          darcy Joe Darcy made changes -
          Link This issue csr of CCC-8143413 [ CCC-8143413 ]

            People

            • Assignee:
              ntv Nadeesh Tv (Inactive)
              Reporter:
              rriggs Roger Riggs
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: