| Most of that complication is there because times and dates are actually complicated. You can have a nice simple API that doesn't expose the complication only if you're happy for it to encourage false assumptions and wrong behaviour. But, still, let's look at your first couple of complaints. To make #1 more explicit: If you want the equivalent of "new Date()", then as you observe you need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does? To make #2 more explicit: If you want the equivalent of "Date.now()", then as you observe you again need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does? Well, because as those two examples show there isn't actually an obvious simple thing. Two operations both of which one might expect to do the obvious simple thing do different things, and if there's some obvious way for someone who doesn't already happen to have the specs of Date memorized to know which one is "new Date()" and which one is "Date.now()", I don't know what it is. So, to me, those first two examples look like pretty convincing evidence that Temporal is a better design and one that's less likely to lead non-experts to make serious mistakes. ... And then your other two complaints aren't actually about the API being "too complicated" at all! PascalCase isn't more complicated than snakeCase. Nanoseconds aren't more complicated than milliseconds. (Also: "zonedDateTimeISO" and "epochMilliseconds" are in fact both snakeCase, and a quick look at the Temporal documentation suggests that this is the norm. Method names are snakeCase, class names are PascalCase. I am not a Javascript expert but isn't that pretty normal?) |