| ▲ | evolve2k 3 hours ago | |
Firstly, I really want this also and am supportive of an opinionated decision to put something at say Temporal.DateTime() that would be logical for developers to use ‘most of the time’. However my guess is that the spec designers saw this lack of specivity as part of the problem. A key issue of dates and times is that we use them culturally in day to day use in very imprecise ways and much is inferred from the context of use. The concepts of zoned time and “wall clock” time are irreducable and it’s likely much code will be improved by forcing the developer to be explicit with the form of time they want to use and need for their particular use case. I think this is why it’s so explicitly specified right now. But I agree; I’ve often struggled with how verbose js can be. Maybe with time (pun intended), more syntactic sugar and shorter conventions can be added to expand what has been an incredible effort to fix deep rooted issues. | ||