Reputation: 1
I am getting getTimestampMillis() from a SmsMessage sms and trying to convert that to MM/dd/yy hh:mm a.
I am using the code below, which works except it returns an hour ahead. Example it is 6-28-15 9:22 pm, the code returns 6-28-15 10:22 pm. I have read this is a java bug because London didnt observe GMT in 1970, or something similar. Is there a fix, or workaround that doesn't require me to subtract an hour in the summer and then change the code back after DST?
long time = currentMessage.getTimestampMillis();
Log.i(TAG, "time stamp in millis= "+time);
Time date = new Time(time);
DateFormat format = new SimpleDateFormat("MM/dd/yy hh:mm a");
String timestamp = format.format(date);
Log.i(TAG, "Human readable timestamp= "+timestamp);
Upvotes: 0
Views: 333
Reputation: 339917
Instant.ofEpochMilli( millisSinceEpoch )
GMT represents mean solar time, and is practically synonymous with UTC. Do not confuse this with the time zone Europe/London
which has observed Daylight Saving Time (DST).
Never use java.sql.Time
, DateFormat
, or any of the legacy date-time classes bundled with the earliest versions of Java.
The modern solution uses java.time classes.
I assume your count of milliseconds was since the epoch reference of first moment of 1970 in UTC, 1970-01-01T00:00Z.
long millisSinceEpoch = currentMessage.getTimestampMillis();
Convert to a Instant
object.
Instant instant = Instant.ofEpochMilli( millisSinceEpoch ) ;
An Instant
is always in UTC, by definition. So you will not have any surprises from Daylight Saving Time (DST).
Generate text in standard ISO 8601 format.
String output = instant.toString() ;
You did not specify your example value of epoch milliseconds. But we can work backwards to deduce it.
// Example it is 6-28-15 9:22
LocalDate ld = LocalDate.of( 2015 , Month.JUNE , 28 ) ;
LocalTime lt = LocalTime.of( 9 , 22 ) ;
LocalDateTime ldt = LocalDateTime.of( ld , lt ) ;
OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC ) ;
Instant instant = odt.toInstant() ;
long epochMilli = instant.toEpochMilli() ;
1435483320000
See this code run live at IdeOne.com.
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
.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
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. Hibernate 5 & JPA 2.2 support java.time.
Where to obtain the java.time classes?
Upvotes: 2
Reputation: 187
UTC and GMT are two different things. UTC does not experience DST, whereas GMT does. Two steps:
1. Find out what time standard your host is actually using (java will be using this).
2. Probably just ignore that completely, and explicitly declare which timezone you want to use.
And if you find that playing with timezones is tedious, annoying, and confusing, consider using library joda-time. It's much more versatile and pleasant to use than built-in java stuff.
Upvotes: -1