How do I get POSIX time (UTC) from a serial value local date-time with the Java 8 DateTime API

问题

I have a timestamp that is similar to POSIX Time with the sole exception that it is not reckoned in UTC.

Instead, it is the number of milliseconds that have elapsed since midnight, Jan 1 1970 in a particular local time zone. In order to make this value into an Instant, I must first know its offset (in milliseconds) to UTC/GMT.

So the problem is this: knowing the local time zone id, eg. "America/Chicago" and a count of milliseconds since the local Epoch, how do I make an Instant (which must be constructed with milliseconds since the POSIX Epoch)?

It does not seem that any of the java.time API constructors accept a millisecond parameter in a local Epoch.

I have a solution in which I first convert the local millisecond date-time into the local Gregorian calendar date-time (from which I can then construct a LocalDateTime and get the offset to UTC), but this seems like a lot of churning for what seems like it ought to be pretty simple.

回答1:

Calculate the instant of your modified epoch:

ZoneId tz = ZoneId.of("America/Chicago");
Instant modifiedEpoch = ZonedDateTime.of(1970, 1, 1, 0, 0, 0, 0, tz).toInstant();

Then add your millis:

Instant instant = modifiedEpoch.plusMillis(millis);

回答2:

Wrong Way To Track Date-Time

First I have to say this use of count-from-epoch integers for date-time values in various time zones rather than in UTC is a really, really bad idea. I’ve seen some bad ways to handle date-time including inventing one or two bad ways myself. But this one is the worst. Whoever thought this up should be sentenced to a year of daily readings of StackOverflow answers marked "java", "date", and "Jon Skeet".

Using count-from-epoch to handle date-time in your app code is like using bit arrays to handle text. We have classes/interfaces such as CharSequence, String, StringBuilder, Printer, Reader and so on to handle the nitty-gritty complicated details of text, characters, character encoding, collations, and such for us to make writing apps easier. Imagine trying to debug, troubleshoot, and log textual data as bit arrays. Crazy, right? Trying to debug, troubleshoot, and log date-time data as long integers is crazy too.

Ditto for date-time, where we had Joda-Time and now have its successor java.time (Tutorial) built into Java 8 and later.

Secondly, implicitly adjusting a count-from-epoch into a time zone and then losing that fact makes a bad practice even worse.

Fix

The way to fix this is to get that count-from-epoch in some arbitrary time zone translated into a local date and local time where local means the wall-clock time as seen by people in than time zone.

With that local date-time in hand, we create a date-time object that has the assigned time zone, a ZonedDateTime. A ZonedDateTime is basically an Instant (a point on the timeline in UTC) plus a ZoneId (a time zone).

Since the author of the Question failed to supply any sample data, let's create a value in this screwy fashion. Get the current moment in Chicago time zone. Get a legitimate count-from-epoch, adjusting from nanosecond resolution to millisecond. Then arbitrarily add/subtract the offset from UTC for that time zone.

In this example we use the time zone America/Chicago. It's offset for our sample, with Daylight Saving Time, is -05:00. In milliseconds, 5 * 60 * 60 * 1,000 = 18,000,000.

    // First, create sample data, a count-from-epoch but not in UTC, instead adjusted for the time zone’s offset.
ZoneId zoneId = ZoneId.of( "America/Chicago" );

// 2015-09-19T12:34:56.000-05:00[America/Chicago]
ZonedDateTime zdtTemp = ZonedDateTime.of( 2015 , 9 , 19 , 12 , 34 , 56 , 0 , zoneId );
long millisecondsFromEpoch = zdtTemp.toInstant().toEpochMilli(); // Loosing data, goin from nanosecond
long offsetInMillisecondsForChicagoInDaylightSavingTime = 18_000_000L;  // Offset of `-05:00` is in milliseconds, 5 * 60 * 60 * 1,000 = 18,000,000.
long input = ( millisecondsFromEpoch - offsetInMillisecondsForChicagoInDaylightSavingTime );

Dump to console.

System.out.println( "zoneId : " + zoneId );
System.out.println( "zdtTemp : " + zdtTemp );
System.out.println( "millisecondsFromEpoch : " + millisecondsFromEpoch );
System.out.println( "offsetInMillisecondsForChicagoInDaylightSavingTime : " + offsetInMillisecondsForChicagoInDaylightSavingTime );
System.out.println( "input : " + input );

Now, do the job. Take that screwy input number, pretending it is in UTC even though we know it is not, to produce an Instant. From the Instant, get a LocalDateTime. Now push that LocalDateTime into a time zone to get what we finally want, a ZonedDateTime.

// With example data in hand, proceed to convert to a valid date-time object.
Instant instantPretendingToBeInUtcButNotReally = Instant.ofEpochMilli( input );
LocalDateTime localDateTimeOfPretendInstant = LocalDateTime.ofInstant( instantPretendingToBeInUtcButNotReally , ZoneOffset.UTC );
ZonedDateTime zdt = localDateTimeOfPretendInstant.atZone( zoneId );

Dump to console.

System.out.println( "instantPretendingToBeInUtcButNotReally : " + instantPretendingToBeInUtcButNotReally );
System.out.println( "localDateTimeOfPretendInstant : " + localDateTimeOfPretendInstant );
System.out.println( "zdt : " + zdt );

When run.

zoneId : America/Chicago
zdtTemp : 2015-09-19T12:34:56-05:00[America/Chicago]
millisecondsFromEpoch : 1442684096000
offsetInMillisecondsForChicagoInDaylightSavingTime : 18000000
input : 1442666096000
instantPretendingToBeInUtcButNotReally : 2015-09-19T12:34:56Z
localDateTimeOfPretendInstant : 2015-09-19T12:34:56
zdt : 2015-09-19T12:34:56-05:00[America/Chicago]

---

CAVEAT I did this in rush. Please comment or fix any errors.

回答3:

Because chronological time units are interconvertible, at first blush it might seem that you could have a local date-time in the following double precision format:

57272.5

where...

• 57272 is the day number reckoned from the modified Julian day number epoch (Nov 17, 1858).
• 0.5 is local time expressed as a fraction of one day, e.g. 0.5 = 12:00 noon local time.

There is nothing wrong with expressing a local date-time in this manner. However, numbers are numbers and so instead of a count of days since the modified Julian day number epoch, one can convert this to a count of milliseconds since the POSIX epoch (seemingly) very simply as:

localMillis = ( dayNumber - POSIX_EPOCH_AS_MJD) / (86400.0 * 1000.0);

This is where the notion of "milliseconds since the local epoch" has come from in this case. The mistake here, though, is that there IS NOT a simple one-to-one correspondence between POSIX Epoch millis and "local" epoch millis (the definition of POSIX Time requires that the count be milliseconds from the Epoch in UTC). This is because the local number contains one or more local offsets from UTC that are not guaranteed to be historically consistent (depending on legislation, etc).

These "local" millis can be used as a local time stamp, but they need to be adjusted for historical daylight savings and time zone offsets with the same care that any other time stamp should be. So why use them? I can't think of a reason. Having a time stamp in this format was a mistake.

The solution to this problem that has been employed:

• Convert the "local millis" to a modified Julian day number with the local time expressed as a fraction of one day
• Transform the modified Julian day number to a local Gregorian calendar date and time (algorithm adapted from "Astrological Algorithms", 2nd Ed. by J. Meeus).
• Create a LocalDateTime instance from the local calendar date-time obtained above
• Combine the LocalDateTime with the local ZoneId to contruct a ZonedDateTime, from which an Instant is obtained
• POSIX time as UTC milliseconds from the POSIX Epoch is obtained from the Instant

A code example for this procedure follows:

public static long epochMillisFromLocalMillis(ZoneId tz, long millis) {
    double dayNum = (millis / (86400.0 * 1000.0)) + POSIX_EPOCH_AS_MJD;
    int[] ymd_hmsm = toVectorFromDayNumber(dayNum);

    LocalDateTime ldt = LocalDateTime.of (
            ymd_hmsm[MJD.YEAR],
            ymd_hmsm[MJD.MONTH],
            ymd_hmsm[MJD.DAY],
            ymd_hmsm[MJD.HOURS],
            ymd_hmsm[MJD.MINUTES],
            ymd_hmsm[MJD.SECONDS],
            ymd_hmsm[MJD.MILLIS] * 1000000);
    long utcMillis = ZonedDateTime
            .of(ldt, tz)
            .toInstant()
            .toEpochMilli();
    return utcMillis;    
}

Thanks to Basil Bourque and assylias for their insights on this peculiar problem.

来源：https://stackoverflow.com/questions/32670064/how-do-i-get-posix-time-utc-from-a-serial-value-local-date-time-with-the-java