3

I am receiving data from a server in seconds and I want to convert it to date.

But the seconds I am receiving is not since the UNIX epoch 01/01/1970 but is 01/01/2000.

Normally I'd use:

SimpleDateFormat formatter = new SimpleDateFormat("dd/MM/yyyy", Locale.US);
String dateString = formatter.format(new Date(millisToConvert));

Where millisConvert is converted-to-milliseconds seconds that I receive. But now, naturally, I get wrong dates since the origin is different. How do I change the epoch (the origin) ?

bengongon97
  • 256
  • 2
  • 13
  • 1
    I recommend you avoid the `SimpleDateFormat` class. It is not only long outdated, it is also notoriously troublesome. Today we have so much better in [`java.time`, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/). – Ole V.V. Aug 08 '18 at 07:07

3 Answers3

2

tl;dr

OffsetDateTime.of( 2000 , 1 , 1 , 0 , 0 , 0 , 0 , ZoneOffset.UTC )  // Define your epoch reference moment. 
.pluSeconds( yourSeconds )  // Add the number of seconds given to you. Returns another `OffsetDateTime` object rather than altering the original (immutable objects pattern).  
.toLocalDate()     // Extract a date-only value without time-of-day and without offset-from-UTC. 

java.time

Use the modern java.time classes that supplanted the terrible old legacy classes such as Date & Calendar.

Instant

An Instant represents a moment in UTC.

Define your particular epoch reference date-time.

Instant epoch = Instant.parse( "2000-01-01T00:00Z" ) ;

Add your number of seconds.

Instant later = epoch.plusSeconds( yourSecondsGoHere ) ; 

OffsetDateTime

If you want a date-only value without time-of-day and without time zone, use LocalDate class. First, convert from the basic type Instant to the more flexible OffsetDateTime, specifying the constant ZoneOffset.UTC as the offset.

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

LocalDate

Extract the date-only value.

LocalDate ld = odt.toLocalDate() ;

Table of date-time types in Java, both modern and legacy


About java.time

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

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

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

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

enter image description here

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.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • That's a great answer. I was really started to think that it was not possible so that I have to try find a way to add 30 years to a date. But very very important question here is, the methods you share here is only available in Android API 26 or newer, which is so so new. Any other way you can think of for lower API's for support? It can be long I do not mind as long as it works. – bengongon97 Aug 08 '18 at 07:26
  • @bengongon97 See *ThreeTen-Backport* and *ThreeTenABP* projects. – Basil Bourque Aug 08 '18 at 14:59
1

Add 946080000 seconds to account for the 30 year difference, epoch time should be an long value

Xander May
  • 121
  • 1
  • 10
  • 1
    Add or subtract as needed but also multiply/divide by 1000 to convert millis <-> seconds – Peter Lawrey Aug 07 '18 at 13:02
  • Thanks for both comments but I already tried it. The reason I cannot do that is that method creates integer overflow. :( Any other ideas? – bengongon97 Aug 07 '18 at 13:08
  • Are you using an int or a long? Date takes a long value and we are nowhere near that value in ms – Xander May Aug 07 '18 at 13:47
  • I use long. How that will help us? I dont understand. – bengongon97 Aug 07 '18 at 13:56
  • An integer can store `2^32`, long can store `2^64`. If you're getting an INTEGER overflow then that means the value you're trying to store is larger than 2^32 (ie. 2.147 billion), so you need to use a long, whos value we have not yet exceeded in epoch time – Xander May Aug 07 '18 at 14:54
0

Another way apart from what Basil suggested as I marked as an answer. What Basil suggests works only on API level 26 and higher meaning Android 8.0.0. Nowadays, post-mid 2018, Android 8.0.0 is pretty rare so many devices will not have this functionality.

So I wrote this algorithm:

private long getDateInMilliSeconds (long secondsSinceRippleEpoch){

        Locale.setDefault(Locale.US);

        if (Build.VERSION.SDK_INT >= 26) { //**WHAT BASIL SUGGESTED**
            LocalDateTime desiredDate = OffsetDateTime.of(2000, 1, 1, 0, 0, 0, 0, ZoneOffset.UTC)
                    .plusSeconds(secondsSinceRippleEpoch)
                    .toLocalDateTime();

            Date convertedDate = Date.from(desiredDate.atZone(ZoneId.systemDefault()).toInstant());

            return convertedDate.getTime();
        } else { //MY SOLUTION. Works for both but still I wanted to use the upper
//for higher APIs.

            SimpleDateFormat formatter = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss", Locale.US);
            String dateString = formatter.format(new Date((secondsSinceRippleEpoch+946684800)*1000L )); //To not to cause overflow, use L at the end.

            try {
                Date wantedDate = formatter.parse(dateString);
                return wantedDate.getTime();
            } catch (ParseException e) {
                e.printStackTrace();
                return 200000;
            }

        }

Hope this helps the future visitors.

bengongon97
  • 256
  • 2
  • 13
  • 3
    No need to ever use the troublesome legacy date-time classes. Always use *java.time* classes. For Java 6 & 7 and early Android, see the *ThreeTen-Backport* and *ThreeTenABP* projects. – Basil Bourque Aug 08 '18 at 15:05
  • What makes them troublesome? Why everybody say that? It is because localization errors? Or conversion? – bengongon97 Aug 09 '18 at 08:18
  • 2
    There are many poor design decisions in the legacy classes. Search to learn more. No point in getting into it now. Sun, Oracle, and the JCP community all gave up on those classes years ago with the adoption of JSR 310. – Basil Bourque Aug 09 '18 at 13:14