3

From documentation:

Date Class:

parse(stringDate)

Constructs a Date from a String. The format of the String depends on the local date format.

Datetime Class

parse(datetimeString)

Constructs a Datetime from the given String in the local time zone and in the format of the user locale.

This quite limits the ability of a developer to work with Date/Datetime strings that are in format different from the current user's locale. As a workaround a wrapper utility class should be created to provide the parse(datetimeStringAnyFormat) method that could handle other date/datetime formats.

So why Salesforce don't support parsing different date/datetime strings natively?

  • 1
    I posted an Idea regarding this issue a while back. It's a significant limitation. – David Reed Aug 3 '18 at 15:06
  • I think this is technically off topic but I do understand your frustration. I did upvote the idea. – Kasper Aug 3 '18 at 16:05
  • I understand this might be off topic; I thought someone can clarify the reason why SF didn't implement it for so long. Since parsing dates is a common task, and not having it natively supported by apex is really frustrating. I mean there must be a reason for that. – Eduard Aug 3 '18 at 16:13
2

The reason why, I suspect, is the cost-benefit ratio is far too low to be worth it. Over 99.999% of typical use cases are covered by DateTime.valueOf and DateTime.parse, and the few atypical cases can be solved by other means. Since you asked about Y in an X-Y Problem, I can't really be more specific, but I suspect that whatever it is that you're trying to do could be solved through another technique, without writing a completely new parser that supports arbitrary locales, perhaps by using a JavaScript library like moment.js or something else. There simply isn't enough demand for being able to parse in arbitrary locales that can't be solved through another technique.

  • Thank you, @sfdcfox! You answered the very question, hands down. I would argue the Y nature of my post though, since I was indeed interested in WHY Salesforce did this, without any other context in mind (I mean exact X problem). – Eduard Aug 4 '18 at 6:57
  • 1
    With that said, I still think at least one use case could have been covered by the valueOf or parse methods. It is dates in the "2016-11-17T10:04:31Z" format. One can use JSON.deserialize method to get the DateTime object, which is quite misleading in terms of intent - I want to parse a datetime string, not deserialize JSON. – Eduard Aug 4 '18 at 6:57
  • 1
    @Eduard I agree, it's unfortunate there are some situations that require JSON at all (which shouldn't be true), but like I said, I'm pretty sure it's a cost-benefit thing. And that doesn't mean this might not happen in the future, it's just got to reach a ratio where the cost-benefit ratio is worth it. – sfdcfox Aug 4 '18 at 7:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.