How can I convert seconds since the epoch to hours/minutes/seconds in Java?

Question

Is there a fast, low-garbage way to do it? I can't just do simple modulus arithmetic since that doesn't account for leap seconds and other date/time funny business.

Answer 1

I've figured out how to deal with leap years in integer arithmetic and implemented a converter from seconds since Epoch to date/time (it never gives you more than 59 seconds, though). The below C code should be very easy to port to Java.

#include <string.h>
#include <time.h>

typedef unsigned uint;
typedef unsigned long long uint64;

struct tm* SecondsSinceEpochToDateTime(struct tm* pTm, uint64 SecondsSinceEpoch)
{
  uint64 sec;
  uint quadricentennials, centennials, quadrennials, annuals/*1-ennial?*/;
  uint year, leap;
  uint yday, hour, min;
  uint month, mday, wday;
  static const uint daysSinceJan1st[2][13]=
  {
    {0,31,59,90,120,151,181,212,243,273,304,334,365}, // 365 days, non-leap
    {0,31,60,91,121,152,182,213,244,274,305,335,366}  // 366 days, leap
  };
/*
  400 years:

  1st hundred, starting immediately after a leap year that's a multiple of 400:
  n n n l  \
  n n n l   } 24 times
  ...      /
  n n n l /
  n n n n

  2nd hundred:
  n n n l  \
  n n n l   } 24 times
  ...      /
  n n n l /
  n n n n

  3rd hundred:
  n n n l  \
  n n n l   } 24 times
  ...      /
  n n n l /
  n n n n

  4th hundred:
  n n n l  \
  n n n l   } 24 times
  ...      /
  n n n l /
  n n n L <- 97'th leap year every 400 years
*/

  // Re-bias from 1970 to 1601:
  // 1970 - 1601 = 369 = 3*100 + 17*4 + 1 years (incl. 89 leap days) =
  // (3*100*(365+24/100) + 17*4*(365+1/4) + 1*365)*24*3600 seconds
  sec = SecondsSinceEpoch + 11644473600LL;

  wday = (uint)((sec / 86400 + 1) % 7); // day of week

  // Remove multiples of 400 years (incl. 97 leap days)
  quadricentennials = (uint)(sec / 12622780800ULL); // 400*365.2425*24*3600
  sec %= 12622780800ULL;

  // Remove multiples of 100 years (incl. 24 leap days), can't be more than 3
  // (because multiples of 4*100=400 years (incl. leap days) have been removed)
  centennials = (uint)(sec / 3155673600ULL); // 100*(365+24/100)*24*3600
  if (centennials > 3)
  {
    centennials = 3;
  }
  sec -= centennials * 3155673600ULL;

  // Remove multiples of 4 years (incl. 1 leap day), can't be more than 24
  // (because multiples of 25*4=100 years (incl. leap days) have been removed)
  quadrennials = (uint)(sec / 126230400); // 4*(365+1/4)*24*3600
  if (quadrennials > 24)
  {
    quadrennials = 24;
  }
  sec -= quadrennials * 126230400ULL;

  // Remove multiples of years (incl. 0 leap days), can't be more than 3
  // (because multiples of 4 years (incl. leap days) have been removed)
  annuals = (uint)(sec / 31536000); // 365*24*3600
  if (annuals > 3)
  {
    annuals = 3;
  }
  sec -= annuals * 31536000ULL;

  // Calculate the year and find out if it's leap
  year = 1601 + quadricentennials * 400 + centennials * 100 + quadrennials * 4 + annuals;
  leap = !(year % 4) && (year % 100 || !(year % 400));

  // Calculate the day of the year and the time
  yday = sec / 86400;
  sec %= 86400;
  hour = sec / 3600;
  sec %= 3600;
  min = sec / 60;
  sec %= 60;

  // Calculate the month
  for (mday = month = 1; month < 13; month++)
  {
    if (yday < daysSinceJan1st[leap][month])
    {
      mday += yday - daysSinceJan1st[leap][month - 1];
      break;
    }
  }

  // Fill in C's "struct tm"
  memset(pTm, 0, sizeof(*pTm));
  pTm->tm_sec = sec;          // [0,59]
  pTm->tm_min = min;          // [0,59]
  pTm->tm_hour = hour;        // [0,23]
  pTm->tm_mday = mday;        // [1,31]  (day of month)
  pTm->tm_mon = month - 1;    // [0,11]  (month)
  pTm->tm_year = year - 1900; // 70+     (year since 1900)
  pTm->tm_wday = wday;        // [0,6]   (day since Sunday AKA day of week)
  pTm->tm_yday = yday;        // [0,365] (day since January 1st AKA day of year)
  pTm->tm_isdst = -1;         // daylight saving time flag

  return pTm;
}

See a test run at ideone.

Answer 2

java.time

As of Java 8 and later, the built-in class to use is Instant from the java.time framework.

Instant instant = Instant.ofEpochSecond ( 1_469_168_058L );

Dump to console.

System.out.println ( "instant: " + instant );

instant: 2016-07-22T06:14:18Z

Performance

I do not know exactly how java.time.Instant performs in terms of speed-of-execution or garbage-production. But you should test against this class. In my perusal of the source code in Java 9, it looks pretty simple and fast.

With a few method jumps, it basically just assigns a pair of integers, (a) number of seconds from epoch (a 64-bit long) and (b) a count of nanoseconds as the fraction of a second (a 32-bit int), after doing a couple of quick checks:

First looks for values of zero in which case it returns a static instance for the epoch itself.

if ((seconds | nanoOfSecond) == 0) {
    return EPOCH;
}

Secondly does a sanity-check on the number of seconds against the pair of min/max constants.

if (seconds < MIN_SECOND || seconds > MAX_SECOND) {
    throw new DateTimeException("Instant exceeds minimum or maximum instant");
}

Then calls the constructor, which assigns the pair of integer values to a pair of member variables (long and int primitives respectively).

this.seconds = epochSecond;
this.nanos = nanos;

Of course that is just construction. Interrogating for parts such as time-of-day means more work. As does generating a String via the toString method which involves another class, a DateTimeFormatter. The toString source code is one line.

return DateTimeFormatter.ISO_INSTANT.format(this);

And remember that if you want parts such as year, month, day-of-month, hour, and so forth in a time zone other than UTC, that means more work involving ZoneId and ZonedDateTime classes. For example:

ZoneId zoneId = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone( zoneId );

Answer 3

This is a fast, zero-garbage solution. It is of key importance not to create a new instance of Calendar on each call because it's quite a heavyweight object, taking 448 bytes of heap and almost a microsecond to initialize (Java 6, 64-bit HotSpot, OS X).

HmsCalculator is intended for use from a single thread (each thread must use a different instance).

public class HmsCalculator
{
  private final Calendar c = Calendar.getInstance();

  public Hms toHms(long t) { return toHms(t, new Hms()); }
  public Hms toHms(long t, Hms hms) {
    c.setTimeInMillis(t*1000);
    return hms.init(c);
  }
  public static class Hms {
    public int h, m, s;
    private Hms init(Calendar c) {
      h = c.get(HOUR_OF_DAY); m = c.get(MINUTE); s = c.get(SECOND);
      return this;
    }
    public String toString() { return String.format("%02d:%02d:%02d",h,m,s); }
  }

  public static void main(String[] args) {
    System.out.println(new HmsCalculator().toHms(
       System.currentTimeMillis()/1000));
  }
}

P.S. I didn't paste all those static imports (boring).

Answer 4

Calendar = Calendar.getInstance();
calendar.setTimeInMillis(secondsSinceTheEpoch*1000);

Answer 5

Assuming with "epoch" you mean 01-01-1970, 00:00:00 GMT:

long secondsSinceEpoch = ...;

// The constructor of Date expects milliseconds
// since 01-01-1970, 00:00:00 GMT
Date date = new Date(secondsSinceEpoch * 1000L);

DateFormat df = new SimpleDateFormat("dd/MM/yyyy");
System.out.println(df.format(date)); 

Answer 6

I can't just do simple modulus arithmetic since that doesn't account for leap seconds and other date/time funny business.

Java doesn't account for leap seconds in general - or rather, officially that's up to the platform, but I don't believe it's implemented in any of the common production platforms. Are you sure you need to account for leap seconds? If you do, you should be able to do a simple table-based lookup of the number of seconds to add or remove, depending on what your data source is and what you want it to reflect.

As for "other date/time funny business" - I don't think there is any funny business for this particular calculation. Time zones are irrelevant in terms of elapsed time since the epoch, for example.