Change of `DateTimeFormatter` pattern in Java > 8 [duplicate]
This question already has an answer here:
JDK dateformatter parsing DayOfWeek in German locale, java8 vs java9
2 answers
java.time.format.DateTimeParseException: Text 'Mi Mai 09 09:17:24 2018' could not be parsed at index 0
2 answers
Running:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.LONG,
FormatStyle.LONG,
Chronology.ofLocale(locale),
locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: MMMM d, yyyy h:mm:ss a z // Java 8.0.171-oracle
pattern: MMMM d, y 'at' h:mm:ss a z // Java 11.0.0-open
I found that Oracle uses the iana-tz database (https://data.iana.org/time-zones/tz-link.html) for managing timezone data (see https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html).
However, I did not find anything about such a change of the standard date formatting. Investigating the source code, it seems that in Java 8, the function LocaleResources.getJavaTimeFormatData() loads the sun.text.resources bundle, while in Java 11, it loads the sun.text.resources.cdlr bundle.
My question is:
Is such a change documented somewhere, possibly with a reason for it?
Also, what is the best way to ensure compatibility with existing databases? For now, we have a list of recognized patterns, so I am thinking about adding the old patterns to my list of recognizable patterns by parsing the new patterns.
Another notable change is:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.SHORT, FormatStyle.MEDIUM, Chronology.ofLocale(locale), locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: M/d/yy h:mm:ss a // Java 8.0.171-oracle
pattern: M/d/yy, h:mm:ss a // Java 11.0.0-open
java datetime-format java-time
edited Nov 15 '18 at 10:48
Michael
21k83472
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
marked as duplicate by 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 15 '18 at 10:51
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.
add a comment |
This question already has an answer here:
JDK dateformatter parsing DayOfWeek in German locale, java8 vs java9
2 answers
java.time.format.DateTimeParseException: Text 'Mi Mai 09 09:17:24 2018' could not be parsed at index 0
2 answers
Running:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.LONG,
FormatStyle.LONG,
Chronology.ofLocale(locale),
locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: MMMM d, yyyy h:mm:ss a z // Java 8.0.171-oracle
pattern: MMMM d, y 'at' h:mm:ss a z // Java 11.0.0-open
I found that Oracle uses the iana-tz database (https://data.iana.org/time-zones/tz-link.html) for managing timezone data (see https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html).
However, I did not find anything about such a change of the standard date formatting. Investigating the source code, it seems that in Java 8, the function LocaleResources.getJavaTimeFormatData() loads the sun.text.resources bundle, while in Java 11, it loads the sun.text.resources.cdlr bundle.
My question is:
Is such a change documented somewhere, possibly with a reason for it?
Also, what is the best way to ensure compatibility with existing databases? For now, we have a list of recognized patterns, so I am thinking about adding the old patterns to my list of recognizable patterns by parsing the new patterns.
Another notable change is:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.SHORT, FormatStyle.MEDIUM, Chronology.ofLocale(locale), locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: M/d/yy h:mm:ss a // Java 8.0.171-oracle
pattern: M/d/yy, h:mm:ss a // Java 11.0.0-open
java datetime-format java-time
edited Nov 15 '18 at 10:48
Michael
21k83472
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
marked as duplicate by 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 15 '18 at 10:51
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.
MyLocale.getDefault()is en_US.
– Rémi.B
Nov 15 '18 at 10:47
1
I've tested, and it's a change between 8 and 9.
– Michael
Nov 15 '18 at 10:51
1
Documentation: Removed or changed APIs, scroll down to Use CLDR Locale Data by Default.
– Ole V.V.
Nov 15 '18 at 10:54
1
Also tested running with-Djava.locale.providers=COMPATon Java 9 (as per first dupe) and that keeps the behaviour of Java 8.
– Michael
Nov 15 '18 at 10:55
1
Best way to ensure compatibility of database across Java versions: (1) Store datetimes using the DBMS’ native date and time types, not as strings. (2) If you need to store strings, store ISO 8601 format.
– Ole V.V.
Nov 15 '18 at 11:13
add a comment |
This question already has an answer here:
JDK dateformatter parsing DayOfWeek in German locale, java8 vs java9
2 answers
java.time.format.DateTimeParseException: Text 'Mi Mai 09 09:17:24 2018' could not be parsed at index 0
2 answers
Running:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.LONG,
FormatStyle.LONG,
Chronology.ofLocale(locale),
locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: MMMM d, yyyy h:mm:ss a z // Java 8.0.171-oracle
pattern: MMMM d, y 'at' h:mm:ss a z // Java 11.0.0-open
I found that Oracle uses the iana-tz database (https://data.iana.org/time-zones/tz-link.html) for managing timezone data (see https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html).
However, I did not find anything about such a change of the standard date formatting. Investigating the source code, it seems that in Java 8, the function LocaleResources.getJavaTimeFormatData() loads the sun.text.resources bundle, while in Java 11, it loads the sun.text.resources.cdlr bundle.
My question is:
Is such a change documented somewhere, possibly with a reason for it?
Also, what is the best way to ensure compatibility with existing databases? For now, we have a list of recognized patterns, so I am thinking about adding the old patterns to my list of recognizable patterns by parsing the new patterns.
Another notable change is:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.SHORT, FormatStyle.MEDIUM, Chronology.ofLocale(locale), locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: M/d/yy h:mm:ss a // Java 8.0.171-oracle
pattern: M/d/yy, h:mm:ss a // Java 11.0.0-open
java datetime-format java-time
edited Nov 15 '18 at 10:48
Michael
21k83472
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
This question already has an answer here:
JDK dateformatter parsing DayOfWeek in German locale, java8 vs java9
2 answers
java.time.format.DateTimeParseException: Text 'Mi Mai 09 09:17:24 2018' could not be parsed at index 0
2 answers
Running:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.LONG,
FormatStyle.LONG,
Chronology.ofLocale(locale),
locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: MMMM d, yyyy h:mm:ss a z // Java 8.0.171-oracle
pattern: MMMM d, y 'at' h:mm:ss a z // Java 11.0.0-open
I found that Oracle uses the iana-tz database (https://data.iana.org/time-zones/tz-link.html) for managing timezone data (see https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html).
However, I did not find anything about such a change of the standard date formatting. Investigating the source code, it seems that in Java 8, the function LocaleResources.getJavaTimeFormatData() loads the sun.text.resources bundle, while in Java 11, it loads the sun.text.resources.cdlr bundle.
My question is:
Is such a change documented somewhere, possibly with a reason for it?
Also, what is the best way to ensure compatibility with existing databases? For now, we have a list of recognized patterns, so I am thinking about adding the old patterns to my list of recognizable patterns by parsing the new patterns.
Another notable change is:
Locale locale = Locale.US;
String pattern = DateTimeFormatterBuilder.getLocalizedDateTimePattern(
FormatStyle.SHORT, FormatStyle.MEDIUM, Chronology.ofLocale(locale), locale);
System.out.println("pattern: " + pattern);
Outputs:
pattern: M/d/yy h:mm:ss a // Java 8.0.171-oracle
pattern: M/d/yy, h:mm:ss a // Java 11.0.0-open
This question already has an answer here:
JDK dateformatter parsing DayOfWeek in German locale, java8 vs java9
2 answers
java.time.format.DateTimeParseException: Text 'Mi Mai 09 09:17:24 2018' could not be parsed at index 0
2 answers
java datetime-format java-time
java datetime-format java-time
edited Nov 15 '18 at 10:48
Michael
21k83472
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
edited Nov 15 '18 at 10:48
Michael
21k83472
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
edited Nov 15 '18 at 10:48
Michael
21k83472
edited Nov 15 '18 at 10:48
Michael
21k83472
edited Nov 15 '18 at 10:48
Michael
21k83472
21k83472
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
asked Nov 15 '18 at 10:29
Rémi.BRémi.B
589
589
marked as duplicate by 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 15 '18 at 10:51
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 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 15 '18 at 10:51
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.
MyLocale.getDefault()is en_US.
– Rémi.B
Nov 15 '18 at 10:47
1
I've tested, and it's a change between 8 and 9.
– Michael
Nov 15 '18 at 10:51
1
Documentation: Removed or changed APIs, scroll down to Use CLDR Locale Data by Default.
– Ole V.V.
Nov 15 '18 at 10:54
1
Also tested running with-Djava.locale.providers=COMPATon Java 9 (as per first dupe) and that keeps the behaviour of Java 8.
– Michael
Nov 15 '18 at 10:55
1
Best way to ensure compatibility of database across Java versions: (1) Store datetimes using the DBMS’ native date and time types, not as strings. (2) If you need to store strings, store ISO 8601 format.
– Ole V.V.
Nov 15 '18 at 11:13
add a comment |
MyLocale.getDefault()is en_US.
– Rémi.B
Nov 15 '18 at 10:47
1
I've tested, and it's a change between 8 and 9.
– Michael
Nov 15 '18 at 10:51
1
Documentation: Removed or changed APIs, scroll down to Use CLDR Locale Data by Default.
– Ole V.V.
Nov 15 '18 at 10:54
1
Also tested running with-Djava.locale.providers=COMPATon Java 9 (as per first dupe) and that keeps the behaviour of Java 8.
– Michael
Nov 15 '18 at 10:55
1
Best way to ensure compatibility of database across Java versions: (1) Store datetimes using the DBMS’ native date and time types, not as strings. (2) If you need to store strings, store ISO 8601 format.
– Ole V.V.
Nov 15 '18 at 11:13
My
Locale.getDefault() is en_US.– Rémi.B
Nov 15 '18 at 10:47
My
Locale.getDefault() is en_US.– Rémi.B
Nov 15 '18 at 10:47
1
1
I've tested, and it's a change between 8 and 9.
– Michael
Nov 15 '18 at 10:51
I've tested, and it's a change between 8 and 9.
– Michael
Nov 15 '18 at 10:51
1
1
Documentation: Removed or changed APIs, scroll down to Use CLDR Locale Data by Default.
– Ole V.V.
Nov 15 '18 at 10:54
Documentation: Removed or changed APIs, scroll down to Use CLDR Locale Data by Default.
– Ole V.V.
Nov 15 '18 at 10:54
1
1
Also tested running with
-Djava.locale.providers=COMPAT on Java 9 (as per first dupe) and that keeps the behaviour of Java 8.– Michael
Nov 15 '18 at 10:55
Also tested running with
-Djava.locale.providers=COMPAT on Java 9 (as per first dupe) and that keeps the behaviour of Java 8.– Michael
Nov 15 '18 at 10:55
1
1
Best way to ensure compatibility of database across Java versions: (1) Store datetimes using the DBMS’ native date and time types, not as strings. (2) If you need to store strings, store ISO 8601 format.
– Ole V.V.
Nov 15 '18 at 11:13
Best way to ensure compatibility of database across Java versions: (1) Store datetimes using the DBMS’ native date and time types, not as strings. (2) If you need to store strings, store ISO 8601 format.
– Ole V.V.
Nov 15 '18 at 11:13
add a comment |
0
active
oldest
votes
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
My
Locale.getDefault()is en_US.– Rémi.B
Nov 15 '18 at 10:47
1
I've tested, and it's a change between 8 and 9.
– Michael
Nov 15 '18 at 10:51
1
Documentation: Removed or changed APIs, scroll down to Use CLDR Locale Data by Default.
– Ole V.V.
Nov 15 '18 at 10:54
1
Also tested running with
-Djava.locale.providers=COMPATon Java 9 (as per first dupe) and that keeps the behaviour of Java 8.– Michael
Nov 15 '18 at 10:55
1
Best way to ensure compatibility of database across Java versions: (1) Store datetimes using the DBMS’ native date and time types, not as strings. (2) If you need to store strings, store ISO 8601 format.
– Ole V.V.
Nov 15 '18 at 11:13