4

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?

Improve this question
3
  • 1
    I posted an Idea regarding this issue a while back. It's a significant limitation.
    – David Reed ♦
    Aug 3, 2018 at 15:06
  • I think this is technically off topic but I do understand your frustration. I did upvote the idea.
    – Kasper
    Aug 3, 2018 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, 2018 at 16:13

1 Answer 1

Reset to default
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.

Improve this answer
3
  • 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, 2018 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, 2018 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, 2018 at 7:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .