Unparseable date exception (1980-02-22T00:00:00Z) [duplicate]
-1
This question already has an answer here:
Converting ISO 8601-compliant String to java.util.Date
25 answers
ISO 8601 String to Date/Time object in Android
4 answers
I'm trying to parse 1980-02-22T00:00:00Z into "java.util.Date" using
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'").parse(stringdate)
But I got error
caused by: java.text.ParseException: Unparseable date.
How to parse String like this into Date to get time in milliseconds? I've tried to use SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'") and SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
java date kotlin
edited Nov 22 '18 at 9:15
veben
1,2492921
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
marked as duplicate by GPI, Ole V.V. java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 22 '18 at 11:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
|
show 2 more comments
-1
This question already has an answer here:
Converting ISO 8601-compliant String to java.util.Date
25 answers
ISO 8601 String to Date/Time object in Android
4 answers
I'm trying to parse 1980-02-22T00:00:00Z into "java.util.Date" using
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'").parse(stringdate)
But I got error
caused by: java.text.ParseException: Unparseable date.
How to parse String like this into Date to get time in milliseconds? I've tried to use SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'") and SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
java date kotlin
edited Nov 22 '18 at 9:15
veben
1,2492921
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
marked as duplicate by GPI, Ole V.V. java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 22 '18 at 11:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
6
Please don't use the legacyjava.util.Dateclass if you can possibly avoid it. You should instead use the class in thejava.timepackage that is appropriate for your use case.
– Joe C
Nov 22 '18 at 8:04
3
Since there’s no .SS remove that but keep the ‘Z’?
– Sami Kuhmonen
Nov 22 '18 at 8:04
1
I advice you to use class "LocalDateTime" introduced by java 8 instead of "Date" : docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
– veben
Nov 22 '18 at 8:11
1
Instant.parse( "1980-02-22T00:00:00Z" )is all you need.
– Basil Bourque
Nov 22 '18 at 21:11
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:50
|
show 2 more comments
-1
-1
-1
This question already has an answer here:
Converting ISO 8601-compliant String to java.util.Date
25 answers
ISO 8601 String to Date/Time object in Android
4 answers
I'm trying to parse 1980-02-22T00:00:00Z into "java.util.Date" using
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'").parse(stringdate)
But I got error
caused by: java.text.ParseException: Unparseable date.
How to parse String like this into Date to get time in milliseconds? I've tried to use SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'") and SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
java date kotlin
edited Nov 22 '18 at 9:15
veben
1,2492921
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
This question already has an answer here:
Converting ISO 8601-compliant String to java.util.Date
25 answers
ISO 8601 String to Date/Time object in Android
4 answers
I'm trying to parse 1980-02-22T00:00:00Z into "java.util.Date" using
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'").parse(stringdate)
But I got error
caused by: java.text.ParseException: Unparseable date.
How to parse String like this into Date to get time in milliseconds? I've tried to use SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'") and SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
This question already has an answer here:
Converting ISO 8601-compliant String to java.util.Date
25 answers
ISO 8601 String to Date/Time object in Android
4 answers
java date kotlin
java date kotlin
edited Nov 22 '18 at 9:15
veben
1,2492921
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
edited Nov 22 '18 at 9:15
veben
1,2492921
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
edited Nov 22 '18 at 9:15
veben
1,2492921
edited Nov 22 '18 at 9:15
veben
1,2492921
edited Nov 22 '18 at 9:15
veben
1,2492921
1,2492921
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
asked Nov 22 '18 at 8:01
StrangeloveStrangelove
297
297
marked as duplicate by GPI, Ole V.V. java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 22 '18 at 11:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by GPI, Ole V.V. java
Users with the java badge can single-handedly close java questions as duplicates and reopen them as needed.
StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;
$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');
$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Nov 22 '18 at 11:50
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
6
Please don't use the legacyjava.util.Dateclass if you can possibly avoid it. You should instead use the class in thejava.timepackage that is appropriate for your use case.
– Joe C
Nov 22 '18 at 8:04
3
Since there’s no .SS remove that but keep the ‘Z’?
– Sami Kuhmonen
Nov 22 '18 at 8:04
1
I advice you to use class "LocalDateTime" introduced by java 8 instead of "Date" : docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
– veben
Nov 22 '18 at 8:11
1
Instant.parse( "1980-02-22T00:00:00Z" )is all you need.
– Basil Bourque
Nov 22 '18 at 21:11
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:50
|
show 2 more comments
6
Please don't use the legacyjava.util.Dateclass if you can possibly avoid it. You should instead use the class in thejava.timepackage that is appropriate for your use case.
– Joe C
Nov 22 '18 at 8:04
3
Since there’s no .SS remove that but keep the ‘Z’?
– Sami Kuhmonen
Nov 22 '18 at 8:04
1
I advice you to use class "LocalDateTime" introduced by java 8 instead of "Date" : docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
– veben
Nov 22 '18 at 8:11
1
Instant.parse( "1980-02-22T00:00:00Z" )is all you need.
– Basil Bourque
Nov 22 '18 at 21:11
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:50
6
6
Please don't use the legacy
java.util.Date class if you can possibly avoid it. You should instead use the class in the java.time package that is appropriate for your use case.– Joe C
Nov 22 '18 at 8:04
Please don't use the legacy
java.util.Date class if you can possibly avoid it. You should instead use the class in the java.time package that is appropriate for your use case.– Joe C
Nov 22 '18 at 8:04
3
3
Since there’s no .SS remove that but keep the ‘Z’?
– Sami Kuhmonen
Nov 22 '18 at 8:04
Since there’s no .SS remove that but keep the ‘Z’?
– Sami Kuhmonen
Nov 22 '18 at 8:04
1
1
I advice you to use class "LocalDateTime" introduced by java 8 instead of "Date" : docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
– veben
Nov 22 '18 at 8:11
I advice you to use class "LocalDateTime" introduced by java 8 instead of "Date" : docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
– veben
Nov 22 '18 at 8:11
1
1
Instant.parse( "1980-02-22T00:00:00Z" ) is all you need.– Basil Bourque
Nov 22 '18 at 21:11
Instant.parse( "1980-02-22T00:00:00Z" ) is all you need.– Basil Bourque
Nov 22 '18 at 21:11
1
1
FYI, the terribly troublesome old date-time classes such as
java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.– Basil Bourque
Nov 23 '18 at 5:50
FYI, the terribly troublesome old date-time classes such as
java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.– Basil Bourque
Nov 23 '18 at 5:50
|
show 2 more comments
2 Answers
2
active
oldest
votes
6
Just replace:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'")
by:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
1
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".Zin the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you doSimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).
– GPI
Nov 22 '18 at 8:25
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:45
add a comment |
2
If you can use java8, you can use LocalDateTime class,
you can do below:
As per suggestions below, I have corrected my code to parse the date.
String text = "1980-02-22T12:10:02Z";
LocalDateTime dateTime = LocalDateTime.ofInstant(Instant.parse(text),ZoneOffset.UTC);
System.out.println(dateTime);
Result:
1980-02-22T12:10:02
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
1
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
1
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
Okay - what If I make the change to returndatetimeinUTCtimezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am sayingUTChere just for example.
– secret super star
Nov 22 '18 at 9:15
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
|
show 7 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
6
Just replace:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'")
by:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
1
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".Zin the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you doSimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).
– GPI
Nov 22 '18 at 8:25
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:45
add a comment |
6
Just replace:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'")
by:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
1
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".Zin the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you doSimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).
– GPI
Nov 22 '18 at 8:25
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:45
add a comment |
6
6
6
Just replace:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'")
by:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
Just replace:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SS'Z'")
by:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'");
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
answered Nov 22 '18 at 8:08
vebenveben
1,2492921
1,2492921
1
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".Zin the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you doSimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).
– GPI
Nov 22 '18 at 8:25
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:45
add a comment |
1
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".Zin the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you doSimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).
– GPI
Nov 22 '18 at 8:25
1
FYI, the terribly troublesome old date-time classes such asjava.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 23 '18 at 5:45
1
1
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".
Z in the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you do SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'") you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).– GPI
Nov 22 '18 at 8:25
It works, as in "it does not crash", but it does not, as in "it is not a correct parsing of the date".
Z in the end is not a neutral character. It has a meaning ("the hour is in the UTC time zone"). When you do SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'") you get a parser that will ignore the 'Z', and treat the hour in the system's timezone, which, of course, is System and User dependant, and not reproducible. In other words, it is a bug. If you want to parse a ISO8601 date, use a ISO8601 parser (e.g. from the XML package or java.time package).– GPI
Nov 22 '18 at 8:25
1
1
FYI, the terribly troublesome old date-time classes such as
java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.– Basil Bourque
Nov 23 '18 at 5:45
FYI, the terribly troublesome old date-time classes such as
java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.– Basil Bourque
Nov 23 '18 at 5:45
add a comment |
2
If you can use java8, you can use LocalDateTime class,
you can do below:
As per suggestions below, I have corrected my code to parse the date.
String text = "1980-02-22T12:10:02Z";
LocalDateTime dateTime = LocalDateTime.ofInstant(Instant.parse(text),ZoneOffset.UTC);
System.out.println(dateTime);
Result:
1980-02-22T12:10:02
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
1
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
1
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
Okay - what If I make the change to returndatetimeinUTCtimezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am sayingUTChere just for example.
– secret super star
Nov 22 '18 at 9:15
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
|
show 7 more comments
2
If you can use java8, you can use LocalDateTime class,
you can do below:
As per suggestions below, I have corrected my code to parse the date.
String text = "1980-02-22T12:10:02Z";
LocalDateTime dateTime = LocalDateTime.ofInstant(Instant.parse(text),ZoneOffset.UTC);
System.out.println(dateTime);
Result:
1980-02-22T12:10:02
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
1
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
1
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
Okay - what If I make the change to returndatetimeinUTCtimezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am sayingUTChere just for example.
– secret super star
Nov 22 '18 at 9:15
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
|
show 7 more comments
2
2
2
If you can use java8, you can use LocalDateTime class,
you can do below:
As per suggestions below, I have corrected my code to parse the date.
String text = "1980-02-22T12:10:02Z";
LocalDateTime dateTime = LocalDateTime.ofInstant(Instant.parse(text),ZoneOffset.UTC);
System.out.println(dateTime);
Result:
1980-02-22T12:10:02
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
If you can use java8, you can use LocalDateTime class,
you can do below:
As per suggestions below, I have corrected my code to parse the date.
String text = "1980-02-22T12:10:02Z";
LocalDateTime dateTime = LocalDateTime.ofInstant(Instant.parse(text),ZoneOffset.UTC);
System.out.println(dateTime);
Result:
1980-02-22T12:10:02
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
edited Nov 23 '18 at 6:11
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
answered Nov 22 '18 at 8:17
secret super starsecret super star
943114
943114
1
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
1
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
Okay - what If I make the change to returndatetimeinUTCtimezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am sayingUTChere just for example.
– secret super star
Nov 22 '18 at 9:15
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
|
show 7 more comments
1
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
1
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
Okay - what If I make the change to returndatetimeinUTCtimezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am sayingUTChere just for example.
– secret super star
Nov 22 '18 at 9:15
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
1
1
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
See my comment at @veben's answer. This is a wrong solution, because it ignores the 'Z' in the end, which is a TimeZone information. Therefore, the parsing result may or may not be accurate, depending on the JVM's default timezone (which is system dependant).
– GPI
Nov 22 '18 at 8:35
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
Agreed, but OP did not mention about if he wanted to convert time into particular timezone. However, I would look into the link you have provided in the question comments and update answer if I can provide more helpful and detailed answer.
– secret super star
Nov 22 '18 at 9:04
1
1
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
The OP does not have to convert, or even want to convert anything to anywhere. If you System.out.println(date.getMillis()) in your code, set your system clock to London, run it once, then set your system clock to New York, run it again, you'll get different results. Your sample code is system dependant, and 1980-02-22T12:10:02Z is a perfectly defined date that depends on nothing. So, a valid parsing of it should not depend on the system timezone. It is not about what the user wants to convert to. It is about making sure the parsing returns the correct point in time in any System setting.
– GPI
Nov 22 '18 at 9:08
Okay - what If I make the change to return
datetime in UTC timezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am saying UTC here just for example.– secret super star
Nov 22 '18 at 9:15
Okay - what If I make the change to return
datetime in UTC timezone. so it always returns in UTC irrespective of system settings. so, would it be acceptable? I am saying UTC here just for example.– secret super star
Nov 22 '18 at 9:15
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
Of course, it would help. But if you want it to really work, you'd have to find if it is UTC or "something else", e.g. if it ends with Z or "+0100" or whatever... Which is the point of my comments. The "Z" means something, and it could be something else than Z, so we can not ignore it. And in the end, you use DateTimeFormatter.ISO_DATE_TIME.
– GPI
Nov 22 '18 at 9:22
|
show 7 more comments
6
Please don't use the legacy
java.util.Dateclass if you can possibly avoid it. You should instead use the class in thejava.timepackage that is appropriate for your use case.– Joe C
Nov 22 '18 at 8:04
3
Since there’s no .SS remove that but keep the ‘Z’?
– Sami Kuhmonen
Nov 22 '18 at 8:04
1
I advice you to use class "LocalDateTime" introduced by java 8 instead of "Date" : docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
– veben
Nov 22 '18 at 8:11
1
Instant.parse( "1980-02-22T00:00:00Z" )is all you need.– Basil Bourque
Nov 22 '18 at 21:11
1
FYI, the terribly troublesome old date-time classes such as
java.util.Date,java.util.Calendar, andjava.text.SimpleDateFormatare now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.– Basil Bourque
Nov 23 '18 at 5:50