Cookbook: Parsing localized timestamps

[nicolasr75]

What is the general strategy for parsing timestamps that a user entered in localized format (non ISO 8601)?

F.e. in a German locale a user may enter '22.01.2022 13:45:00'.

Assuming the software knows the time zone, the calendar and the locale, I would like to end up with a (UTC) Instance for internal arithmetics.

What do you recommend for parsing user input? Is there already any documentation about this?

[ptomato]

We have mostly considered parsing (other than deserialization of ISO 8601-like strings) to be in the domain of business logic and outside the scope of Temporal (since everybody knows their own use case for parsing other formats better than Temporal possibly can, and to avoid repeating the mistakes of Date.parse().) Therefore this functionality isn't part of Temporal.

Here's some discussion about how it might be supported in the future: js-temporal/proposal-temporal-v2#2

What I'd recommend depends on your use case, and how robust it needs to be. I think for most cases I'd recommend parsing by splitting strings or using regular expressions, tailored to the format that you are parsing, and then constructing one of the wall-clock-aware objects (e.g. PlainDate, PlainDateTime) using number values that you obtain from the string. Then you can convert that to Instant using the appropriate time zone, to obtain an exact time.

By the way, I'm assuming that once Temporal is more widely adopted, libraries will start appearing that will provide this functionality.

I hope that answers your question!

[nicolasr75]

Thanks for answering. I understand your arguments.

Let me just explain why I think that the domain of business logic for me is not a good place:
Our software is meant for the international market. It will have to support formats that I don't even know. On the other side there seem to be standard formats for displaying timestamps, f.e. 18.01.2022 (Germany), 18/01/2022, (France), 01/18/2022 (US). We don't plan to support parsing each and every imaginable format (full month name + day name 2-digit year etc. etc.) but for many of our users it would increase productivity a lot when they could enter timestamps in text fields. Selecting specific dates with datepickers or entering dates in multiple controls (day, month, year separately) can be quite tedious. A text field can include the localized format specifier in its label. All it needs is a dynamic way for the software to determine standard format specifiers according to the given locale and a parsing function that takes that specifier. But I understand that you don't want to overload Temporal with locale information.

I'd prefer a world with ISO strings, UTC, unified calendars and without daylight savings time but unfortunately that is not in my choice ;-)

(the issue could be closed from my side)

[ptomato]

I see, so your question is not about users inputting data in one locale-specific format, but in any locale-specific format? That might be more appropriate for the Intl object (but: see tc39/ecma402#342) but even that could have wildly varying implementations depending on your business logic (see, for example, tc39/ecma402#342 (comment))

I think it might be nice to document in the Temporal cookbook how to parse a particular expected format as I described above, so maybe it's a good idea to keep this issue open in order to do that.

[nicolasr75]

Thanks for that link, very interesting. I can only underline the points made in this comment tc39/ecma402#342 (comment) but I also understand arguments agains string parsing. I think it very much depends on the target user group. In our case it's a limited group of international power users. These guys work with timestamps and measured values all day. Selecting a specific date and time with one of the common date and time pickers needs up to 10 clicks (at least when it's located in another year and month)! When you have to do that 30 times a day you start getting mad at the software developer. And that's exactly where the strict parser that reverses the output of some format function comes into play. These power users are happy to stick to a given (localized) format an accept an error message now and then when they have mistyped the timestamp string. I could force them to use ISO format but then they would complain "Why do I have to use that strange format? My local date format works in Excel!!!".

I agree with others that this usage may probably not be a good idea for public web sites for everyone. It would just be nice if the develop has a choice. And the idea that every developer (usually not an expert in Date parsing) comes up with her own solution sounds terrible to me.

OK, let's keep the issue open. Am curious to see how it turns out. Apart from that working with Temporal is such a great joy!