Reputation: 39
I used this SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
.So when I pass date 2016-01-01T10:30:00-0800
more than or equal to 10:30:00-0800 time then it will parse(date) response which is next day date 2016-01-02T00:00:00+0530 which is not expected.It changes date by one day.If I give 2016-01-01T10:20:00-0800 then give exact date.So if time should be less t10:30:00-0800 then get expected result otherwise next day date.
Full code:
SimpleDateFormat dt = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
public Date deserialize(JsonParser jsonparser, DeserializationContext arg1) {
String date = jsonparser.getText();
dt.parse(date);
}
Upvotes: 0
Views: 2766
Reputation: 338336
You are using old outmoded date-time classes that have proven to be poorly designed, confusing, and troublesome. Use java.time instead.
The java.time framework is built into Java 8 and later. These classes supplant the old troublesome date-time classes such as java.util.Date
, .Calendar
, & java.text.SimpleDateFormat
. The Joda-Time team also advises migration to java.time.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.
Your input string complies with ISO 8601 standard. These standard formats are used by default in java.time classes. So no need to specify a formatting pattern.
Your input value has an offset-from-UTC, a number of 8 hours behind UTC.
The OffsetDateTime
class represents such values.
OffsetDateTime odt = OffsetDateTime.parse( "2016-01-01T10:30:00-0800" );
A time zone is an offset-from-UTC plus a set of rules for handling anomalies such as Daylight Saving Time (DST). If you are certain of the time zone intended as the context for this value, apply it to get a ZonedDateTime
.
Specify a time zone (ZoneId
) by a proper time zone name in format of continent/region
. Never use the 3-4 letter abbreviations such as EST
or IST
as they are not true time zones, are not standardized, and are not even unique(!).
ZoneId zoneId = ZoneId.of( "America/Los_Angeles" );
ZonedDateTime zdt = odt.atZone( zoneId );
If you want to see this value through the lens of local time in India, you can apply a different time zone to create a new ZonedDateTime
. The java.time classes use the immutable objects pattern. So note that rather than alter (“mutate”) the time zone setting on an existing object, the java.time classes create a new object with some of its members based on the original object’s members.
ZonedDateTime zdt_Kolkata = zdt.withZoneSameInstant( ZoneId.of( "Asia/Kolkata" ) ) ;
Upvotes: 0
Reputation: 21435
It's important to understand that an instance of the class java.util.Date
is not a calendar date but a moment in time.
Converting a java.util.Date
to and from a string representation always involves time zones.
Your input is 2016-01-01T10:30:00-0800
, indicating a zone offset of -8 hours (which is the timezone of Los Angeles, USA). That moment in time corresponds to 2016-01-01T18:30:00+0000
in a zone with an offset of 0 hours (like London, GB) or to 2016-01-02T00:00:00+0530
within your local time zone.
That is fine if you want to store the moment a meeting in Los Angeles begins and show that moment in different time zones.
If you want to represent dates (like birthdays) that have no inherent time information you should better use java.time.LocalDate
(if you are using Java 8) or org.joda.time.LocalDate
(if Java 8 is not an option).
Upvotes: 3