Re:Temporal: Getting started with JavaScript's new date time...
by symlinkk on Monday June 28, 2021 @07:33PM
(#27669711)
If you’re parsing human readable strings to determine a datetime in your codebase you messed up somewhere. The user should select a datetime with a picker that uses a calendar and dropdown menus (no freeform text input). Everywhere from then on in your code you should pass it around using some standard, either as a UNIX timestamp or ISO8601.
Re:Temporal: Getting started with JavaScript's new date time...
by dheera on Monday June 28, 2021 @07:53PM
(#27669859)
Well no, the problem is I very frequently have to interface with APIs that give me human readable time strings only. Those APIs were not written by top quality engineers and I often have no other choice or way to interface with those systems.
Also you mention ISO-8601 but this document does not even describe how to input an ISO-8601 string.
Re:Temporal: Getting started with JavaScript's new date time...
by filoeleven on Monday June 28, 2021 @08:58PM
(#27670364)
…until you’re working on an app for servicing companies, shipping departments, etc. where on some forms nearly 1/2 of the input fields can be dates. Then your users hate you because they can’t just tab > type > tab to enter a date.
I agree with you on the rest though. And I would love to be able to enforce ISO 8601 for text entry of dates.
Well shit, that's one of the biggest things I want from a time library. There are about 15 different forms of human readable string formats that various APIs give you in their JSON responses and if they don't solve that, they haven't solved the biggest pain point.
I guess congratulations for not solving the problem and instead making Javascript even more complicated to use by introducing yet another incomplete date library that skirts around perhaps the most important feature and which millions of hippie JS devs will jump on the bandwagon to use.