Formatting ISO 8601 date with a colon seperator
I am trying to convert the date in milliseconds to the following ISO 8601 format:
But I am getting the following using SimpleDateFormat:
/**
* It converts the time from long to the ISO format
*
* @param timestampMillis
* @return isoDate
*/
public String convertTimeMillisToISO8601(String timestampMillis)
{
long timeInLong= Long.parseLong(timestampMillis);
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
String isoDate = df.format(new java.util.Date(timeInLong));
return isoDate;
}
OUTPUT:
"ts":"2015-06-18T09:56:21+0000"
I know I can use substring to append the extra colon but Is there any better way to do so ?
java date iso8601
add a comment |
I am trying to convert the date in milliseconds to the following ISO 8601 format:
But I am getting the following using SimpleDateFormat:
/**
* It converts the time from long to the ISO format
*
* @param timestampMillis
* @return isoDate
*/
public String convertTimeMillisToISO8601(String timestampMillis)
{
long timeInLong= Long.parseLong(timestampMillis);
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
String isoDate = df.format(new java.util.Date(timeInLong));
return isoDate;
}
OUTPUT:
"ts":"2015-06-18T09:56:21+0000"
I know I can use substring to append the extra colon but Is there any better way to do so ?
java date iso8601
1
Did you tryX
for the timezone?
– user1907906
Apr 15 '15 at 8:17
based on this question and answer i think it's not supported in JavaSimpleDateFormat
stackoverflow.com/questions/2201925/…
– Yazan
Apr 15 '15 at 8:24
@Tichodroma - yes, all it prints is for UTC it will print Z.
– My God
Apr 15 '15 at 8:49
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:57
add a comment |
I am trying to convert the date in milliseconds to the following ISO 8601 format:
But I am getting the following using SimpleDateFormat:
/**
* It converts the time from long to the ISO format
*
* @param timestampMillis
* @return isoDate
*/
public String convertTimeMillisToISO8601(String timestampMillis)
{
long timeInLong= Long.parseLong(timestampMillis);
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
String isoDate = df.format(new java.util.Date(timeInLong));
return isoDate;
}
OUTPUT:
"ts":"2015-06-18T09:56:21+0000"
I know I can use substring to append the extra colon but Is there any better way to do so ?
java date iso8601
I am trying to convert the date in milliseconds to the following ISO 8601 format:
But I am getting the following using SimpleDateFormat:
/**
* It converts the time from long to the ISO format
*
* @param timestampMillis
* @return isoDate
*/
public String convertTimeMillisToISO8601(String timestampMillis)
{
long timeInLong= Long.parseLong(timestampMillis);
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
df.setTimeZone(TimeZone.getTimeZone("UTC"));
String isoDate = df.format(new java.util.Date(timeInLong));
return isoDate;
}
OUTPUT:
"ts":"2015-06-18T09:56:21+0000"
I know I can use substring to append the extra colon but Is there any better way to do so ?
java date iso8601
java date iso8601
asked Apr 15 '15 at 8:15
My God
16.9k1975135
16.9k1975135
1
Did you tryX
for the timezone?
– user1907906
Apr 15 '15 at 8:17
based on this question and answer i think it's not supported in JavaSimpleDateFormat
stackoverflow.com/questions/2201925/…
– Yazan
Apr 15 '15 at 8:24
@Tichodroma - yes, all it prints is for UTC it will print Z.
– My God
Apr 15 '15 at 8:49
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:57
add a comment |
1
Did you tryX
for the timezone?
– user1907906
Apr 15 '15 at 8:17
based on this question and answer i think it's not supported in JavaSimpleDateFormat
stackoverflow.com/questions/2201925/…
– Yazan
Apr 15 '15 at 8:24
@Tichodroma - yes, all it prints is for UTC it will print Z.
– My God
Apr 15 '15 at 8:49
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:57
1
1
Did you try
X
for the timezone?– user1907906
Apr 15 '15 at 8:17
Did you try
X
for the timezone?– user1907906
Apr 15 '15 at 8:17
based on this question and answer i think it's not supported in Java
SimpleDateFormat
stackoverflow.com/questions/2201925/…– Yazan
Apr 15 '15 at 8:24
based on this question and answer i think it's not supported in Java
SimpleDateFormat
stackoverflow.com/questions/2201925/…– Yazan
Apr 15 '15 at 8:24
@Tichodroma - yes, all it prints is for UTC it will print Z.
– My God
Apr 15 '15 at 8:49
@Tichodroma - yes, all it prints is for UTC it will print Z.
– My God
Apr 15 '15 at 8:49
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 12 at 19:57
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 12 at 19:57
add a comment |
5 Answers
5
active
oldest
votes
You can always use a StringBuilder:
new StringBuilder(
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
.format(date))
.insert(22,':')
.toString();
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:58
add a comment |
For Java 7 and higher, you might use XXX
(ISO 8601 time zone) in the date format String. According to the documentation the documentation, the result of X
can be:
X => -08
XX => -0800
XXX => -08:00
but for all of those, it might as well return Z
!
For Java 6 and earlier, there is no X
(J6 doc), and since the result of X
may or may not do what you want, I strongly recommend you just insert that colon yourself.
2
X
will produceZ
for UTC, not+00:00
.
– Bram
Apr 15 '15 at 8:35
Yes, it says so in the documentation I liked to. It may generate the desired result, orZ
. That's why I would really just insert the colon myself.
– Siguza
Apr 15 '15 at 8:47
add a comment |
Can you use Java 8?
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd'T'HH:mm:ssXXX");
System.out.println(formatter.format(ZonedDateTime.now()));
2015-04-15T17:24:19+09:00
Also for UTC? That's where the XXX went wrong for theSimpleDateFormat
.
– Bram
Apr 15 '15 at 8:31
2
For UTC it will printZ
– Raniz
Apr 15 '15 at 8:33
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
TheOffsetDateTime
is appropriate here with this Question, as the input involves+00:00
. No time zone is indicated in the Question, soZonedDateTime
is not the best fit.
– Basil Bourque
Nov 12 at 20:13
|
show 1 more comment
tl;dr
OffsetDateTime.parse( "2014-06-18T09:56:21+00:00" )
2014-06-18T09:56:21Z
Details
Some other answers are close, correct in using the modern java.time classes that supplanted the terrible old legacy classes (Date
, Calendar
, SimpleDateFormat
). But they are either working too hard or chose the wrong class.
ISO 8601
Your format is in standard ISO 8601 format. The java.time classes use these standard formats by default when parsing/generating text representing their date-time values. So you need not specify any formatting pattern at all. Works by default.
OffsetDateTime
Your input indicates an offset-from-UTC of zero hours and zero minutes. So we should use the OffsetDateTime
class.
String input = "2014-06-18T09:56:21+00:00";
OffsetDateTime odt = OffsetDateTime.parse( input );
Zulu time
We can generate a string in standard ISO 8601 format by merely calling toString
. The Z
on the end means UTC, and is pronounced “Zulu”.
odt.toString(): 2014-06-18T09:56:21Z
ZonedDateTime
If your input indicated a time zone, rather than merely an offset, we would have used ZonedDateTime
class. An offset is simply a number of hours, minutes, and seconds – nothing more. A time zone is much more. A time zone is a history of past, present, and future changes to the offset used by the people of a particular region.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- Later versions of Android bundle implementations of the java.time classes.
- For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
add a comment |
For Java 8 if you use one of the standard ISO_DATE_*
format patterns then the output formatted String will be truncated when the offset is +00:00 (UTC typically just appends Z
).
OffsetDateTime utcWithFractionOfSecond = ZonedDateTime.parse("2018-01-10T12:00:00.000000+00:00", DateTimeFormatter.ISO_OFFSET_DATE_TIME);
utcWithFractionOfSecond.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME); // 2018-01-10T12:00:00Z ... not what you want!
The only solution I have found is using the outputPattern
(shown below) that uses lowercase `xxx' to ensure that a colon is included in the timezone offset.
I have included an example with factions-of-a-second for completeness (you can remove the SSSSSS
in your case)
DateTimeFormatter inputPattern = DateTimeFormatter.ISO_OFFSET_DATE_TIME;
DateTimeFormatter outputPattern = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx");
OffsetDateTime utcWithFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00.000000+00:00", inputPattern);
OffsetDateTime utcNoFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00+00:00", inputPattern);
OffsetDateTime utcWithZ = OffsetDateTime.parse("2018-01-10T12:00:00Z", inputPattern);
OffsetDateTime utcPlus3Hours = OffsetDateTime.parse("2018-01-10T12:00:00.000000+03:00", inputPattern);|
utcWithFractionOfSecond.format(outputPattern ); // 2018-01-10T12:00:00.000000+00:00
utcNoFractionOfSecond.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcWithZ.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcPlus3Hours.format(outputPattern); // 2018-01-10T12:00:00.000000+03:00
In these examples I have used ISO_OFFSET_DATE_TIME only to create the input values for the test cases. In all cases it is the outputPattern yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx
that controlling how to include a colon character in the timezone portion of your resulting formatted string.
Note that if your input data included the Zone ID like [Europe/London]
then you would create your input data using ZonedDateTime instead of OffsetDateTime
The input string indicates only an offset, not a time zone. SoOffsetDateTime
class is appropriate here, notZonedDateTime
.
– Basil Bourque
Nov 12 at 20:09
Agreed, I have updated the answer to be more specific about usingOffsetDateTime
in this particular example
– Brad
Nov 13 at 10:32
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f29645020%2fformatting-iso-8601-date-with-a-colon-seperator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can always use a StringBuilder:
new StringBuilder(
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
.format(date))
.insert(22,':')
.toString();
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:58
add a comment |
You can always use a StringBuilder:
new StringBuilder(
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
.format(date))
.insert(22,':')
.toString();
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:58
add a comment |
You can always use a StringBuilder:
new StringBuilder(
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
.format(date))
.insert(22,':')
.toString();
You can always use a StringBuilder:
new StringBuilder(
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ")
.format(date))
.insert(22,':')
.toString();
edited May 23 '17 at 10:28
Community♦
11
11
answered Apr 15 '15 at 8:46
OldCurmudgeon
51.4k1384167
51.4k1384167
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:58
add a comment |
FYI, the terribly troublesome old date-time classes such asjava.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.
– Basil Bourque
Nov 12 at 19:58
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 12 at 19:58
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 12 at 19:58
add a comment |
For Java 7 and higher, you might use XXX
(ISO 8601 time zone) in the date format String. According to the documentation the documentation, the result of X
can be:
X => -08
XX => -0800
XXX => -08:00
but for all of those, it might as well return Z
!
For Java 6 and earlier, there is no X
(J6 doc), and since the result of X
may or may not do what you want, I strongly recommend you just insert that colon yourself.
2
X
will produceZ
for UTC, not+00:00
.
– Bram
Apr 15 '15 at 8:35
Yes, it says so in the documentation I liked to. It may generate the desired result, orZ
. That's why I would really just insert the colon myself.
– Siguza
Apr 15 '15 at 8:47
add a comment |
For Java 7 and higher, you might use XXX
(ISO 8601 time zone) in the date format String. According to the documentation the documentation, the result of X
can be:
X => -08
XX => -0800
XXX => -08:00
but for all of those, it might as well return Z
!
For Java 6 and earlier, there is no X
(J6 doc), and since the result of X
may or may not do what you want, I strongly recommend you just insert that colon yourself.
2
X
will produceZ
for UTC, not+00:00
.
– Bram
Apr 15 '15 at 8:35
Yes, it says so in the documentation I liked to. It may generate the desired result, orZ
. That's why I would really just insert the colon myself.
– Siguza
Apr 15 '15 at 8:47
add a comment |
For Java 7 and higher, you might use XXX
(ISO 8601 time zone) in the date format String. According to the documentation the documentation, the result of X
can be:
X => -08
XX => -0800
XXX => -08:00
but for all of those, it might as well return Z
!
For Java 6 and earlier, there is no X
(J6 doc), and since the result of X
may or may not do what you want, I strongly recommend you just insert that colon yourself.
For Java 7 and higher, you might use XXX
(ISO 8601 time zone) in the date format String. According to the documentation the documentation, the result of X
can be:
X => -08
XX => -0800
XXX => -08:00
but for all of those, it might as well return Z
!
For Java 6 and earlier, there is no X
(J6 doc), and since the result of X
may or may not do what you want, I strongly recommend you just insert that colon yourself.
edited Apr 15 '15 at 8:44
answered Apr 15 '15 at 8:24
Siguza
12.2k63351
12.2k63351
2
X
will produceZ
for UTC, not+00:00
.
– Bram
Apr 15 '15 at 8:35
Yes, it says so in the documentation I liked to. It may generate the desired result, orZ
. That's why I would really just insert the colon myself.
– Siguza
Apr 15 '15 at 8:47
add a comment |
2
X
will produceZ
for UTC, not+00:00
.
– Bram
Apr 15 '15 at 8:35
Yes, it says so in the documentation I liked to. It may generate the desired result, orZ
. That's why I would really just insert the colon myself.
– Siguza
Apr 15 '15 at 8:47
2
2
X
will produce Z
for UTC, not +00:00
.– Bram
Apr 15 '15 at 8:35
X
will produce Z
for UTC, not +00:00
.– Bram
Apr 15 '15 at 8:35
Yes, it says so in the documentation I liked to. It may generate the desired result, or
Z
. That's why I would really just insert the colon myself.– Siguza
Apr 15 '15 at 8:47
Yes, it says so in the documentation I liked to. It may generate the desired result, or
Z
. That's why I would really just insert the colon myself.– Siguza
Apr 15 '15 at 8:47
add a comment |
Can you use Java 8?
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd'T'HH:mm:ssXXX");
System.out.println(formatter.format(ZonedDateTime.now()));
2015-04-15T17:24:19+09:00
Also for UTC? That's where the XXX went wrong for theSimpleDateFormat
.
– Bram
Apr 15 '15 at 8:31
2
For UTC it will printZ
– Raniz
Apr 15 '15 at 8:33
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
TheOffsetDateTime
is appropriate here with this Question, as the input involves+00:00
. No time zone is indicated in the Question, soZonedDateTime
is not the best fit.
– Basil Bourque
Nov 12 at 20:13
|
show 1 more comment
Can you use Java 8?
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd'T'HH:mm:ssXXX");
System.out.println(formatter.format(ZonedDateTime.now()));
2015-04-15T17:24:19+09:00
Also for UTC? That's where the XXX went wrong for theSimpleDateFormat
.
– Bram
Apr 15 '15 at 8:31
2
For UTC it will printZ
– Raniz
Apr 15 '15 at 8:33
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
TheOffsetDateTime
is appropriate here with this Question, as the input involves+00:00
. No time zone is indicated in the Question, soZonedDateTime
is not the best fit.
– Basil Bourque
Nov 12 at 20:13
|
show 1 more comment
Can you use Java 8?
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd'T'HH:mm:ssXXX");
System.out.println(formatter.format(ZonedDateTime.now()));
2015-04-15T17:24:19+09:00
Can you use Java 8?
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd'T'HH:mm:ssXXX");
System.out.println(formatter.format(ZonedDateTime.now()));
2015-04-15T17:24:19+09:00
answered Apr 15 '15 at 8:26
Raniz
8,27312155
8,27312155
Also for UTC? That's where the XXX went wrong for theSimpleDateFormat
.
– Bram
Apr 15 '15 at 8:31
2
For UTC it will printZ
– Raniz
Apr 15 '15 at 8:33
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
TheOffsetDateTime
is appropriate here with this Question, as the input involves+00:00
. No time zone is indicated in the Question, soZonedDateTime
is not the best fit.
– Basil Bourque
Nov 12 at 20:13
|
show 1 more comment
Also for UTC? That's where the XXX went wrong for theSimpleDateFormat
.
– Bram
Apr 15 '15 at 8:31
2
For UTC it will printZ
– Raniz
Apr 15 '15 at 8:33
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
TheOffsetDateTime
is appropriate here with this Question, as the input involves+00:00
. No time zone is indicated in the Question, soZonedDateTime
is not the best fit.
– Basil Bourque
Nov 12 at 20:13
Also for UTC? That's where the XXX went wrong for the
SimpleDateFormat
.– Bram
Apr 15 '15 at 8:31
Also for UTC? That's where the XXX went wrong for the
SimpleDateFormat
.– Bram
Apr 15 '15 at 8:31
2
2
For UTC it will print
Z
– Raniz
Apr 15 '15 at 8:33
For UTC it will print
Z
– Raniz
Apr 15 '15 at 8:33
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
@Raniz - yes so I am talking about UTC.
– My God
Apr 15 '15 at 8:52
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
No need to specify a formatting pattern. The standard ISO 8601 format of the input string is handled by default in the java.time classes.
– Basil Bourque
Nov 12 at 20:12
The
OffsetDateTime
is appropriate here with this Question, as the input involves +00:00
. No time zone is indicated in the Question, so ZonedDateTime
is not the best fit.– Basil Bourque
Nov 12 at 20:13
The
OffsetDateTime
is appropriate here with this Question, as the input involves +00:00
. No time zone is indicated in the Question, so ZonedDateTime
is not the best fit.– Basil Bourque
Nov 12 at 20:13
|
show 1 more comment
tl;dr
OffsetDateTime.parse( "2014-06-18T09:56:21+00:00" )
2014-06-18T09:56:21Z
Details
Some other answers are close, correct in using the modern java.time classes that supplanted the terrible old legacy classes (Date
, Calendar
, SimpleDateFormat
). But they are either working too hard or chose the wrong class.
ISO 8601
Your format is in standard ISO 8601 format. The java.time classes use these standard formats by default when parsing/generating text representing their date-time values. So you need not specify any formatting pattern at all. Works by default.
OffsetDateTime
Your input indicates an offset-from-UTC of zero hours and zero minutes. So we should use the OffsetDateTime
class.
String input = "2014-06-18T09:56:21+00:00";
OffsetDateTime odt = OffsetDateTime.parse( input );
Zulu time
We can generate a string in standard ISO 8601 format by merely calling toString
. The Z
on the end means UTC, and is pronounced “Zulu”.
odt.toString(): 2014-06-18T09:56:21Z
ZonedDateTime
If your input indicated a time zone, rather than merely an offset, we would have used ZonedDateTime
class. An offset is simply a number of hours, minutes, and seconds – nothing more. A time zone is much more. A time zone is a history of past, present, and future changes to the offset used by the people of a particular region.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- Later versions of Android bundle implementations of the java.time classes.
- For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
add a comment |
tl;dr
OffsetDateTime.parse( "2014-06-18T09:56:21+00:00" )
2014-06-18T09:56:21Z
Details
Some other answers are close, correct in using the modern java.time classes that supplanted the terrible old legacy classes (Date
, Calendar
, SimpleDateFormat
). But they are either working too hard or chose the wrong class.
ISO 8601
Your format is in standard ISO 8601 format. The java.time classes use these standard formats by default when parsing/generating text representing their date-time values. So you need not specify any formatting pattern at all. Works by default.
OffsetDateTime
Your input indicates an offset-from-UTC of zero hours and zero minutes. So we should use the OffsetDateTime
class.
String input = "2014-06-18T09:56:21+00:00";
OffsetDateTime odt = OffsetDateTime.parse( input );
Zulu time
We can generate a string in standard ISO 8601 format by merely calling toString
. The Z
on the end means UTC, and is pronounced “Zulu”.
odt.toString(): 2014-06-18T09:56:21Z
ZonedDateTime
If your input indicated a time zone, rather than merely an offset, we would have used ZonedDateTime
class. An offset is simply a number of hours, minutes, and seconds – nothing more. A time zone is much more. A time zone is a history of past, present, and future changes to the offset used by the people of a particular region.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- Later versions of Android bundle implementations of the java.time classes.
- For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
add a comment |
tl;dr
OffsetDateTime.parse( "2014-06-18T09:56:21+00:00" )
2014-06-18T09:56:21Z
Details
Some other answers are close, correct in using the modern java.time classes that supplanted the terrible old legacy classes (Date
, Calendar
, SimpleDateFormat
). But they are either working too hard or chose the wrong class.
ISO 8601
Your format is in standard ISO 8601 format. The java.time classes use these standard formats by default when parsing/generating text representing their date-time values. So you need not specify any formatting pattern at all. Works by default.
OffsetDateTime
Your input indicates an offset-from-UTC of zero hours and zero minutes. So we should use the OffsetDateTime
class.
String input = "2014-06-18T09:56:21+00:00";
OffsetDateTime odt = OffsetDateTime.parse( input );
Zulu time
We can generate a string in standard ISO 8601 format by merely calling toString
. The Z
on the end means UTC, and is pronounced “Zulu”.
odt.toString(): 2014-06-18T09:56:21Z
ZonedDateTime
If your input indicated a time zone, rather than merely an offset, we would have used ZonedDateTime
class. An offset is simply a number of hours, minutes, and seconds – nothing more. A time zone is much more. A time zone is a history of past, present, and future changes to the offset used by the people of a particular region.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- Later versions of Android bundle implementations of the java.time classes.
- For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
tl;dr
OffsetDateTime.parse( "2014-06-18T09:56:21+00:00" )
2014-06-18T09:56:21Z
Details
Some other answers are close, correct in using the modern java.time classes that supplanted the terrible old legacy classes (Date
, Calendar
, SimpleDateFormat
). But they are either working too hard or chose the wrong class.
ISO 8601
Your format is in standard ISO 8601 format. The java.time classes use these standard formats by default when parsing/generating text representing their date-time values. So you need not specify any formatting pattern at all. Works by default.
OffsetDateTime
Your input indicates an offset-from-UTC of zero hours and zero minutes. So we should use the OffsetDateTime
class.
String input = "2014-06-18T09:56:21+00:00";
OffsetDateTime odt = OffsetDateTime.parse( input );
Zulu time
We can generate a string in standard ISO 8601 format by merely calling toString
. The Z
on the end means UTC, and is pronounced “Zulu”.
odt.toString(): 2014-06-18T09:56:21Z
ZonedDateTime
If your input indicated a time zone, rather than merely an offset, we would have used ZonedDateTime
class. An offset is simply a number of hours, minutes, and seconds – nothing more. A time zone is much more. A time zone is a history of past, present, and future changes to the offset used by the people of a particular region.
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?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
- Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
- Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
- Later versions of Android bundle implementations of the java.time classes.
- For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
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.
edited Nov 12 at 21:39
answered Nov 12 at 20:09
Basil Bourque
106k25362526
106k25362526
add a comment |
add a comment |
For Java 8 if you use one of the standard ISO_DATE_*
format patterns then the output formatted String will be truncated when the offset is +00:00 (UTC typically just appends Z
).
OffsetDateTime utcWithFractionOfSecond = ZonedDateTime.parse("2018-01-10T12:00:00.000000+00:00", DateTimeFormatter.ISO_OFFSET_DATE_TIME);
utcWithFractionOfSecond.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME); // 2018-01-10T12:00:00Z ... not what you want!
The only solution I have found is using the outputPattern
(shown below) that uses lowercase `xxx' to ensure that a colon is included in the timezone offset.
I have included an example with factions-of-a-second for completeness (you can remove the SSSSSS
in your case)
DateTimeFormatter inputPattern = DateTimeFormatter.ISO_OFFSET_DATE_TIME;
DateTimeFormatter outputPattern = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx");
OffsetDateTime utcWithFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00.000000+00:00", inputPattern);
OffsetDateTime utcNoFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00+00:00", inputPattern);
OffsetDateTime utcWithZ = OffsetDateTime.parse("2018-01-10T12:00:00Z", inputPattern);
OffsetDateTime utcPlus3Hours = OffsetDateTime.parse("2018-01-10T12:00:00.000000+03:00", inputPattern);|
utcWithFractionOfSecond.format(outputPattern ); // 2018-01-10T12:00:00.000000+00:00
utcNoFractionOfSecond.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcWithZ.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcPlus3Hours.format(outputPattern); // 2018-01-10T12:00:00.000000+03:00
In these examples I have used ISO_OFFSET_DATE_TIME only to create the input values for the test cases. In all cases it is the outputPattern yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx
that controlling how to include a colon character in the timezone portion of your resulting formatted string.
Note that if your input data included the Zone ID like [Europe/London]
then you would create your input data using ZonedDateTime instead of OffsetDateTime
The input string indicates only an offset, not a time zone. SoOffsetDateTime
class is appropriate here, notZonedDateTime
.
– Basil Bourque
Nov 12 at 20:09
Agreed, I have updated the answer to be more specific about usingOffsetDateTime
in this particular example
– Brad
Nov 13 at 10:32
add a comment |
For Java 8 if you use one of the standard ISO_DATE_*
format patterns then the output formatted String will be truncated when the offset is +00:00 (UTC typically just appends Z
).
OffsetDateTime utcWithFractionOfSecond = ZonedDateTime.parse("2018-01-10T12:00:00.000000+00:00", DateTimeFormatter.ISO_OFFSET_DATE_TIME);
utcWithFractionOfSecond.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME); // 2018-01-10T12:00:00Z ... not what you want!
The only solution I have found is using the outputPattern
(shown below) that uses lowercase `xxx' to ensure that a colon is included in the timezone offset.
I have included an example with factions-of-a-second for completeness (you can remove the SSSSSS
in your case)
DateTimeFormatter inputPattern = DateTimeFormatter.ISO_OFFSET_DATE_TIME;
DateTimeFormatter outputPattern = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx");
OffsetDateTime utcWithFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00.000000+00:00", inputPattern);
OffsetDateTime utcNoFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00+00:00", inputPattern);
OffsetDateTime utcWithZ = OffsetDateTime.parse("2018-01-10T12:00:00Z", inputPattern);
OffsetDateTime utcPlus3Hours = OffsetDateTime.parse("2018-01-10T12:00:00.000000+03:00", inputPattern);|
utcWithFractionOfSecond.format(outputPattern ); // 2018-01-10T12:00:00.000000+00:00
utcNoFractionOfSecond.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcWithZ.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcPlus3Hours.format(outputPattern); // 2018-01-10T12:00:00.000000+03:00
In these examples I have used ISO_OFFSET_DATE_TIME only to create the input values for the test cases. In all cases it is the outputPattern yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx
that controlling how to include a colon character in the timezone portion of your resulting formatted string.
Note that if your input data included the Zone ID like [Europe/London]
then you would create your input data using ZonedDateTime instead of OffsetDateTime
The input string indicates only an offset, not a time zone. SoOffsetDateTime
class is appropriate here, notZonedDateTime
.
– Basil Bourque
Nov 12 at 20:09
Agreed, I have updated the answer to be more specific about usingOffsetDateTime
in this particular example
– Brad
Nov 13 at 10:32
add a comment |
For Java 8 if you use one of the standard ISO_DATE_*
format patterns then the output formatted String will be truncated when the offset is +00:00 (UTC typically just appends Z
).
OffsetDateTime utcWithFractionOfSecond = ZonedDateTime.parse("2018-01-10T12:00:00.000000+00:00", DateTimeFormatter.ISO_OFFSET_DATE_TIME);
utcWithFractionOfSecond.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME); // 2018-01-10T12:00:00Z ... not what you want!
The only solution I have found is using the outputPattern
(shown below) that uses lowercase `xxx' to ensure that a colon is included in the timezone offset.
I have included an example with factions-of-a-second for completeness (you can remove the SSSSSS
in your case)
DateTimeFormatter inputPattern = DateTimeFormatter.ISO_OFFSET_DATE_TIME;
DateTimeFormatter outputPattern = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx");
OffsetDateTime utcWithFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00.000000+00:00", inputPattern);
OffsetDateTime utcNoFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00+00:00", inputPattern);
OffsetDateTime utcWithZ = OffsetDateTime.parse("2018-01-10T12:00:00Z", inputPattern);
OffsetDateTime utcPlus3Hours = OffsetDateTime.parse("2018-01-10T12:00:00.000000+03:00", inputPattern);|
utcWithFractionOfSecond.format(outputPattern ); // 2018-01-10T12:00:00.000000+00:00
utcNoFractionOfSecond.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcWithZ.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcPlus3Hours.format(outputPattern); // 2018-01-10T12:00:00.000000+03:00
In these examples I have used ISO_OFFSET_DATE_TIME only to create the input values for the test cases. In all cases it is the outputPattern yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx
that controlling how to include a colon character in the timezone portion of your resulting formatted string.
Note that if your input data included the Zone ID like [Europe/London]
then you would create your input data using ZonedDateTime instead of OffsetDateTime
For Java 8 if you use one of the standard ISO_DATE_*
format patterns then the output formatted String will be truncated when the offset is +00:00 (UTC typically just appends Z
).
OffsetDateTime utcWithFractionOfSecond = ZonedDateTime.parse("2018-01-10T12:00:00.000000+00:00", DateTimeFormatter.ISO_OFFSET_DATE_TIME);
utcWithFractionOfSecond.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME); // 2018-01-10T12:00:00Z ... not what you want!
The only solution I have found is using the outputPattern
(shown below) that uses lowercase `xxx' to ensure that a colon is included in the timezone offset.
I have included an example with factions-of-a-second for completeness (you can remove the SSSSSS
in your case)
DateTimeFormatter inputPattern = DateTimeFormatter.ISO_OFFSET_DATE_TIME;
DateTimeFormatter outputPattern = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx");
OffsetDateTime utcWithFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00.000000+00:00", inputPattern);
OffsetDateTime utcNoFractionOfSecond = OffsetDateTime.parse("2018-01-10T12:00:00+00:00", inputPattern);
OffsetDateTime utcWithZ = OffsetDateTime.parse("2018-01-10T12:00:00Z", inputPattern);
OffsetDateTime utcPlus3Hours = OffsetDateTime.parse("2018-01-10T12:00:00.000000+03:00", inputPattern);|
utcWithFractionOfSecond.format(outputPattern ); // 2018-01-10T12:00:00.000000+00:00
utcNoFractionOfSecond.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcWithZ.format(outputPattern); // 2018-01-10T12:00:00.000000+00:00
utcPlus3Hours.format(outputPattern); // 2018-01-10T12:00:00.000000+03:00
In these examples I have used ISO_OFFSET_DATE_TIME only to create the input values for the test cases. In all cases it is the outputPattern yyyy-MM-dd'T'HH:mm:ss.SSSSSSxxx
that controlling how to include a colon character in the timezone portion of your resulting formatted string.
Note that if your input data included the Zone ID like [Europe/London]
then you would create your input data using ZonedDateTime instead of OffsetDateTime
edited Nov 13 at 10:31
answered Nov 12 at 12:41
Brad
10.4k74465
10.4k74465
The input string indicates only an offset, not a time zone. SoOffsetDateTime
class is appropriate here, notZonedDateTime
.
– Basil Bourque
Nov 12 at 20:09
Agreed, I have updated the answer to be more specific about usingOffsetDateTime
in this particular example
– Brad
Nov 13 at 10:32
add a comment |
The input string indicates only an offset, not a time zone. SoOffsetDateTime
class is appropriate here, notZonedDateTime
.
– Basil Bourque
Nov 12 at 20:09
Agreed, I have updated the answer to be more specific about usingOffsetDateTime
in this particular example
– Brad
Nov 13 at 10:32
The input string indicates only an offset, not a time zone. So
OffsetDateTime
class is appropriate here, not ZonedDateTime
.– Basil Bourque
Nov 12 at 20:09
The input string indicates only an offset, not a time zone. So
OffsetDateTime
class is appropriate here, not ZonedDateTime
.– Basil Bourque
Nov 12 at 20:09
Agreed, I have updated the answer to be more specific about using
OffsetDateTime
in this particular example– Brad
Nov 13 at 10:32
Agreed, I have updated the answer to be more specific about using
OffsetDateTime
in this particular example– Brad
Nov 13 at 10:32
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f29645020%2fformatting-iso-8601-date-with-a-colon-seperator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Did you try
X
for the timezone?– user1907906
Apr 15 '15 at 8:17
based on this question and answer i think it's not supported in Java
SimpleDateFormat
stackoverflow.com/questions/2201925/…– Yazan
Apr 15 '15 at 8:24
@Tichodroma - yes, all it prints is for UTC it will print Z.
– My God
Apr 15 '15 at 8:49
FYI, the terribly troublesome old date-time classes such as
java.util.Date
,java.util.Calendar
, andjava.text.SimpleDateFormat
are now legacy, supplanted by the java.time classes built into Java 8 and later. See Tutorial by Oracle.– Basil Bourque
Nov 12 at 19:57