Convert LocalTime for given zone to unix epoch seconds without the date component in java

Question

We received time as hour =11, minutes=29,seconds=54,milliseonds=999 along with timezone information.

How to convert this time to unix epoch milliseconds with no date part. I have tried this code :

    ZoneId zoneId = ZoneId.of("America/New_York");
    LocalDate now = LocalDate.now(zoneId);
    long epochMilli = ZonedDateTime.of(LocalDate.now(zoneId).atTime(11, 29, 20, 999 * 1000 * 1000), zoneId).toInstant().toEpochMilli();
    long unixEpocSeconds = epochMilli % (24 * 60 * 60 * 1000); //86400000

    Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone(zoneId));
    calendar.setTimeInMillis(unixEpocSeconds);
    System.out.println("( = " + (calendar.get(Calendar.HOUR)==11));
    System.out.println("( = " + (calendar.get(Calendar.MINUTE)==29));
    System.out.println("( = " + (calendar.get(Calendar.SECOND)==20));
    System.out.println("( = " + (calendar.get(Calendar.MILLISECOND)==999));

How to get the unix epoch seconds without the date component i.e.how to get the milliseconds in UTC zone /rather than as give zoneid. Above code runs find if zoneId=UTC

You can't. The unix epoch seconds is *"the number of seconds since unix epoch (which is `1970-01-01T00:00Z`)"*. If you just have the time and don't have the date, how can you possibly calculate this? — , Sep 26 '17 at 15:43
Another details: `toEpochMilli()` returns the number of **milliseconds** since unix epoch (to get the seconds, call `getEpochSecond()` instead). And to build a `ZonedDateTime`, you could also do `ZonedDateTime.of(LocalDate.now(zoneId).atTime(11, 29, 20, 999 * 1000 * 1000), zoneId)` - a little shorter than calling `getYear()`, `getMonthValue()` and so on. — , Sep 26 '17 at 15:48
@Hugo Thanks . We can't get the epoch milliseconds without the date date . Is it possible to get the miliseonds elapsed since midnight w.r.t UTC? — RGoyal, Sep 26 '17 at 16:16
@Hugo Thanks. We could use the today date for calculating day light shift etc, I have modified the post for details — RGoyal, Sep 26 '17 at 16:29
What's the purpose of `epochMilli % (24 * 60 * 60 * 1000)`? `epochMilli` is the number of milliseconds since epoch. If you want the number of seconds, just divide it by 1000 (or call `getEpochSecond()` instead of `toEpochMilli()`). Then you pass `unixEpocSeconds` (which is supposed to be the number of seconds) to `setTimeInMillis`, which is a method that expects the number of milliseconds. I'm not sure I get what you're trying to do. What should be the correct output, and what you're getting instead? — , Sep 26 '17 at 16:35

Basil Bourque · Answer 1 · 2017-09-26T18:28:15.127

tl;dr

Duration.ofHours( 11L )
        .plusMinutes( 29L )
        .plusSeconds( 54L )
        .plusMillis( 999L ) 
        .toMillis()

41394999

Span-of-time versus Time-of-day

Your Question is confused. A time-of-day without a date makes no sense in comparison to UTC. A count of milliseconds since the Unix epoch reference date of 1970-01-01T00:00:00Z is for tracking the date and the time-of-day.

I suspect you are actually dealing with a span of time, and mishandling that as a time-of-day. One is meant for the timeline, the other is not.

`Duration`

The java.time classes bundled with Java 8 and later include Duration for handling such spans of time unattached to the timeline.

These methods take long data type, hence the trailing L.

Duration d = Duration.ofHours( 11L ).plusMinutes( 29L ).plusSeconds( 54L ).plusMillis( 999L ) ;

Count of milliseconds

You asked for a count of milliseconds, so here you go. Beware of data loss, as a Duration carries a finer resolution of nanoseconds, so you would be lopping off any finer fraction of a second when converting to milliseconds.

long millis = d.toMillis() ;  // Converts this duration to the total length in milliseconds.

41394999

But I suggest you not represent spans of time nor moments on the timeline using a count-of-milliseconds. Better to use objects or standardized text; read on.

ISO 8601

The ISO 8601 standard defines practical unambiguous formats for representing date-time values as text.

This includes representation of durations. The format is PnYnMnDTnHnMnS where the P marks the beginning while the T separates any years-months-days portion from any hours-minutes-seconds portion.

The java.time classes use the standard formats by default in their parse and toString methods.

String output = d.toString() ;

PT11H29M54.999S

See this code run live at IdeOne.com.

You can directly parse such strings in java.time.

Duration d = Duration.parse( "PT11H29M54.999S" ) ;

I suggest using this format whenever possible, certainly when exchanging data between systems.

While working inside Java, pass Duration objects around rather than mere text.

Timeline

You can perform date-time math with the Duration objects. For example, take the current moment in your particular time zone, and add the eleven and a half hours.

ZoneId z = ZoneId.of( "Pacific/Auckland" ) ;
ZonedDateTime now = ZonedDateTime.now( z ) ;
ZonedDateTime later = now.plus( d ) ;

now.toString(): 2017-09-27T07:23:31.651+13:00[Pacific/Auckland]

later.toString(): 2017-09-27T18:53:26.650+13:00[Pacific/Auckland]

For UTC values, call toInstant. The Instant class represents a moment on the timeline in UTC with resolution of nanoseconds (finer than milliseconds).

Instant instant = later.toInstant() ;