• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

How do I turn String yyyyMM into java.util.date?

 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can someone tell me how to solve this problem the easiest way?
I have String 202104 that I want to turn into Date. So, it means it would be year 2021, month 4 and day 00.
 
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A day of '0' is invalid - you will get a day of '1' instead which is the first day of the month.

 
Saloon Keeper
Posts: 13256
292
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why Date, which is really old and sucky, and not YearMonth, which is new and shiny?

I strongly suggest you use YearMonth.parse(). If you REALLY need a Date, you can use SimpleDateFormat.parse().
 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Stephan van Hulst
Saloon Keeper
Posts: 13256
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hmm no that's not how I would parse a YearMonth. Instead, do this:

I'm not sure if BASIC_ISO_DATE will throw an exception when str is missing the day of the month. I don't think it will, but if it does, you can do this:
 
Saloon Keeper
Posts: 24295
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A Java Date and its relatives isn't that simple. All Dates in Java are absolute, internally, and all are counted in milliseconds since Midnight January  1 1970 UTC.

So you not only need to know year, month, and day, you need to know timezone and even that will actually give the value from Midnight of that timezone/day. Anything else is likely to bite you.
 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:I'm not sure if BASIC_ISO_DATE will throw an exception when str is missing the day of the month. I don't think it will, but if it does, you can do this:

Stephan, can you tell me what Locale does here? I thought YearMonth was supposed to be Locale independent.
 
Stephan van Hulst
Saloon Keeper
Posts: 13256
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A YearMonth may be locale independent, but a format string is not. The string "2014" when interpreted as a year may mean something completely different depending on your culture. DateTimeFormatter needs to know the culture to use when intepreting the string.

Whenever you see a method in the API that has an overload that takes a Locale, ALWAYS specify the locale explicitly.

 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stephan, seems like setting the Locale to Locale.ROOT would be dangerous as it could be overriding Locale.getDefault() which is what gets used if you don't supply one.
Output:
They can't be assumed to be the same.

What is the basis of your statement that the Locale "must" be supplied?

 
Stephan van Hulst
Saloon Keeper
Posts: 13256
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Carey Brown wrote:Stephan, seems like setting the Locale to Locale.ROOT would be dangerous as it could be overriding Locale.getDefault() which is what gets used if you don't supply one.

...

What is the basis of your statement that the Locale "must" be supplied?


Overriding the default is exactly why we want to specify the locale explicitly. Using the default is dangerous because its behavior is system dependent and therefore not deterministic.

Many applications rarely have a cause to process strings using the system dependent culture. When you want to process a date that the user entered into your application, you might have a good reason to use their system dependent culture. In almost all other cases, strings are only supplied by other systems or by configuration files that are not associated with a particular culture. In those cases, Locale.ROOT is appropriate.

Even if you did intend to use the current user's default locale, instead of using the overload that doesn't take a locale, pass Locale.getDefault() explicitly. This clearly states that you've thought about your application and that you indeed intended to use the system dependent locale.
 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, little ole me is sitting here in "en_US" and something is wrong with the way my date is being calculated (hypothetically speaking). Now I haven't a clue anymore as to what the behave of ROOT is  where I would have at least had a reasonable guess with "en_US", a.k.a. getDefault() for me.
 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Conversely...

I suppose if you had a database column with a fixed format you wouldn't want the user's locale to interfere with that. I guess it would depend on the origin or destination of the formatted data.
 
Sheriff
Posts: 26773
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had that problem; I upgraded from Java 8 to about Java 14 and my files imported from eBird started to fail. It turned out that somewhere between those versions it was decided that the default date format for the en_CA locale would be "Mmm. dd, yyyy" instead of "Mmm dd, yyyy".

Probably if you looked hard enough you could find release documentation which said that change was going to happen.

But like Stephan said, specifying Locale.US instead of relying on the system default fixed the problem.
 
Saloon Keeper
Posts: 1277
38
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@ Paul:

Was the breaking change the one(s) described here?

https://belief-driven-design.com/localization-changes-java-9-b727e28ef9f/

Locale issues is actually next on my to-study list, after I get thru with Modules Basics, but I had noticed that Big Little Change recently when someone commented about it in an offhand manner in a video I was watching that was purportedly about something else (because they were comparing Java 8 vs. Java 9 behavior).
 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:I had that problem; I upgraded from Java 8 to about Java 14 and my files imported from eBird started to fail. It turned out that somewhere between those versions it was decided that the default date format for the en_CA locale would be "Mmm. dd, yyyy" instead of "Mmm dd, yyyy".

Probably if you looked hard enough you could find release documentation which said that change was going to happen.

But like Stephan said, specifying Locale.US instead of relying on the system default fixed the problem.

If you had used an explicit pattern for parsing wouldn't that have fixed the problem without resorting to Locales?
 
Stephan van Hulst
Saloon Keeper
Posts: 13256
292
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Explicit patterns are still sensitive to locale changes.

For instance, if for some reason you want to save a date (not display it to the user) in medium text style, e.g. "Oct 7, 2021", you can parse it back with the pattern "MMM d, yyyy". However, this will fail miserably on a Dutch system, which expects "okt. 7, 2021".

Unless you specifically meant to process or display user input using their own language, don't use the default locale in string operations. You don't necessarily need to use Locale.ROOT, that's just my personal (but recommended) preference. Locale.ENGLISH, Locale.US or Locale.forLanguageTag("zu-ZA") are all fine, as long as the value doesn't depend on the system settings.
 
Marshal
Posts: 22449
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Indeed. There are at least three things you should never rely on: the locale, the timezone, and the system encoding. Reliance on any of these three will eventually lead to the well known phrase "but it works on my machine".

I remember a time when that happened to me (or probably because of me). I had my Maven options setup to always use UTF-8. And yes, the code worked on my machine. Others that didn't use UTF-8 automatically weren't so lucky. We fixed this by putting the UTF-8 encoding in the Maven configuration, where it belongs.
 
Carey Brown
Saloon Keeper
Posts: 8578
71
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:I had that problem; I upgraded from Java 8 to about Java 14 and my files imported from eBird started to fail. It turned out that somewhere between those versions it was decided that the default date format for the en_CA locale would be "Mmm. dd, yyyy" instead of "Mmm dd, yyyy".

Probably if you looked hard enough you could find release documentation which said that change was going to happen.

But like Stephan said, specifying Locale.US instead of relying on the system default fixed the problem.


Paul, it seems to me that your parse pattern didn't match precisely because you used locale. If you had only specified a pattern you wouldn't have been caught by that change. I'm assuming here that the data from eBird is not locale specific.
 
Stephan van Hulst
Saloon Keeper
Posts: 13256
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Carey Brown wrote:Paul, it seems to me that your parse pattern didn't match precisely because you used locale.


Only if the application had explicitly used "en-CA". That was not the case. The application used the default locale, which just happened to be "en-CA".

I doubt that, if the application had been written with an explicit locale to start with, they would have chosen a locale so specific as "en-CA". More likely would have been "en-US", "en", or the root locale.

If you had only specified a pattern you wouldn't have been caught by that change.


No. If they supplied the pattern "MMM. dd, yyyy" it STILL would have failed on a machine running in China, like I explained in my previous post. Explicit patterns are still locale sensitive.
 
Paul Clapham
Sheriff
Posts: 26773
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I'm assuming here that the data from eBird is not locale specific.



No, eBird is a US organization. And I'm 99.9% certain that the code which generates the downloads is written in Java, based on having seen Java stack traces several years ago when they were a startup.
 
pie. tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic