-1

I'm testing the following value from the list on this site:

Regular date: 500, January 1 = Unix Timestamp: -46388678400

However, running the following Java code on Android:

GregorianCalendar calendar = new GregorianCalendar(500, 0, 1, 0, 0, 0);
calendar.setTimeZone(TimeZone.getTimeZone("UTC"));
Log.d("timestamp", String.valueOf(calendar.getTimeInMillis() / 1000L));
Log.d("date", String.valueOf(calendar.getTime()));

outputs the following results:

-46388592000
Sat Jan 01 02:00:00 GMT+02:00 500

Trying the same online converter and a few other sites with this Unix time stamp I get from my Android program, I get a whole day difference:

Android app:  -46388592000 = Sat Jan 01 00:00:00 GMT
Online sites: -46388592000 = Sat Jan 02 00:00:00 GMT

My question is: who's wrong? The online converter, or the Java code on Android?

Does Android/Java loose accuracy on such big numbers? Or is it because of leap seconds?

TechAurelian
  • 5,561
  • 5
  • 50
  • 65

1 Answers1

2

Avoid old date-time classes

You are using troublesome old date-time classes, now legacy. Avoid them. Supplanted by the java.time classes.

Ancient values not reliable

Do not use date-time values in java.time (nor the old classes) for ancient values such as centuries ago. The date-time types internally count a number of seconds since the epoch of first moment of 1970 UTC. Counting seconds across many past centuries raises issues such as the Julian-Gregorian calendar cut-over. Basically such ancient values are meaningless.

Instead use a LocalDate if you want to represent a date from history.

LocalDate columbusAttacksAmerica = LocalDate.of( "1492-10-12" );

Instant

Though I do not recommending doing so with a historical value, you can parse that large integer as an Instant. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).

long secondsSinceEpoch = -46_388_678_400L;
Instant instant = Instant.ofEpochSecond ( secondsSinceEpoch );

Dump to console.

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

secondsSinceEpoch: -46388678400 | instant: 0500-01-01T00:00:00Z

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old date-time classes such as java.util.Date, .Calendar, & java.text.SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to java.time.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.

Where to obtain the java.time classes?

  • Java SE 8 and SE 9 and later
    • Built-in.
    • Part of the standard Java API with a bundled implementation.
    • Java 9 adds some minor features and fixes.
  • Java SE 6 and SE 7
    • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
  • Android

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • Thank you for your detailed answer, and for the ThreeTenABP info. As an alternative, after re-reading [the documentation](https://developer.android.com/reference/java/util/GregorianCalendar.html#setGregorianChange(java.util.Date)), and adding `calendar.setGregorianChange(new Date(Long.MIN_VALUE));` to my code, I get the same (correct?) results as the online site, and your code using `Instant`. This means they are using a pure Gregorian calendar for all dates, which actually is not historically correct (it was instituted in 1582). What approach do you think is the correct one in this case? – TechAurelian Oct 10 '16 at 08:54