3 ms·
My projects requirements are usually not timezone-aware, and/or I’m slow to see how this helps these. What I’d like to have (in addition, not as a replacement)
by wruza 2y ago
My projects requirements are usually not timezone-aware, and/or I’m slow to see how this helps these.
What I’d like to have (in addition, not as a replacement) is timeless dates. I can store/carry a timezone manually, but give me a proper date[-notime] datatype. I mean, I sort of have it with just “yyyy-mm-dd” and calculating with temporary “T00:00:00Z” suffix. But why would this new format solve my “no timety” impedance mismatch?
More specifically, please give me all the components separately and then design interfaces which may accept any number of these and make sure it makes best sense. Dates without times, times without dates, dates or times with or without timezones, dates without months and/or days, days without years and/or months, weekdays, simply timezones, and so on. Having new dates like subj is yet another piece in the date logic tetris you have to play. Stop imagining developer stories and make them all 1x1 square.
- WickyNilliams 2y agoThe Temporal API discussed here includes PlainDate btw. See https://tc39.es/proposal-temporal/docs/plaindate.html https://tc39.es/proposal-temporal/docs/plaindate.html