如何正确地将新的Date（0L）转换为LocalDate（1970-01-01）？

Question

Consider code:

import org.junit.Test;

import java.time.LocalDate;
import java.time.ZoneId;
import java.util.Date;

import static org.assertj.core.api.Assertions.assertThat;

/**
 * @author nsheremet
 */
public class MyTest {
    private static final Date CREATED_ON = new Date(0L);

    @Test
    public void someTest() {
        LocalDate actualDate = CREATED_ON.toInstant()
                .atZone(ZoneId.systemDefault())
                .toLocalDate();
        assertThat(actualDate).isEqualTo(LocalDate.of(1970, 01, 01));
    }
}

On my machine it works good but on other I got en exception:

[ERROR] Failures: 
[ERROR] MyTest.someTest:23 expected: <19[70-01-0]1> but was:<19[69-12-3]>1 

Why it happens? Using UTC instead of ZoneId.systemDefault() is corrent?

Answer 1

Why it happens? Using UTC instead of ZoneId.systemDefault() is correct?

Yes. EPOCH for java.util.Date is January 1st, 1970 00:00:00.000 UTC , But ZoneId.systemDefault() will fetch what the current computer is configured to use as user time zone. Which is extremely unlikely to be UTC.

So you need to use time zone UTC, rather than anything else.

Answer 2

The possible problem is that your both machines are in different time zones. Check the ZoneId on both machines (if they are the same).

Maybe you want to put defined ZoneId, to ensure that results will always be the same?

Answer 3

tl;dr

Instant
.ofEpochMilli( 0L ) 
.atOffset( 
    ZoneOffset.UTC
)
.toLocalDate()
.toString()

1970-01-01

java.util.Date

java.util.Date represents a moment in UTC, a date with a time-of-day.

Your code:

new Date(0L)

…produced an object representing the first moment of 1970 in UTC, 1970-01-01T00:00:00Z.

Time zone

At that same moment, asking someone on the phone in India to tell you the time-of-day they see on the clock would get you an answer of “5:30 AM”. The time zone Asia/Kolkata at that moment used an offset of five and a half hours ahead of UTC.

If on the phone with someone in Montréal Québec, you would get the answer of “7 PM… of the date 1969-12-31”. The time zone America/Montreal on that date used an offset of five hours behind UTC. Being hours behind midnight in UTC means being on the date behind too, the last day of 1969 rather than the first day of 1970. Ditto for the zone America/New_York and much of the east coast of North America.

So, you must understand that for any given moment, the date varies around the globe, the date varies by zone. When a new day dawns in Japan, it is still “yesterday” in Brazil, for example.

java.time

The Date class is terrible, and should never be used . Along with Calendar it is now legacy, supplanted years ago by the java.time classes. Specifically, Date is replaced by Instant , both classes representing a moment in UTC.

Instant instant = Instant.ofEpochMilli( 0L ) ;

instant.toString(): 1970-01-01T00:00Z

Adjust into the wall-clock time used by the people of a particular region, a time zone. Apply a ZoneId to get a ZonedDateTime object.

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

Extract the date-only portion, without the time-of-day and without the zone.

LocalDate ld = zdt.toLocalDate() ;

ld.toString(): 1969-12-31

If you want to stay in UTC, apply a ZoneOffset constant of ZoneOffset.UTC instead of a ZoneId . And get an OffsetDateTime rather than a ZonedDateTime .

OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ;

Extract the date-only value, a LocalDate .

LocalDate ld = odt.toLocalDate() ;

ld.toString(): 1970-01-01