3 ms·

> but I find the idea that JavaScript (or any language) needs built-in constructs for this purpose to be questionable. Either this, or every project starts wit

> but I find the idea that JavaScript (or any language) needs built-in constructs for this purpose to be questionable. Either this, or every project starts with a 200kb date library import. In reality, I haven't met a single project that I don't need to deal with dates and timezone. And I almost always have a date.ts in my utils library because I don't want to import a giant date library either. But for real, developers shouldn't need to deal with this. These operations and constructs that every sites need should be build into the language itself.

ravenstine 2y ago
> Either this, or every project starts with a 200kb date library import. It's interesting you say this but then go on to explain that you roll your own date library. Doesn't that discredit the idea that the alternative for every project must be a 200kb date library? I agree that most projects work with dates and time zones in some way, but that doesn't mean we'd have to use moment.js in the absence of the Date API. There's plenty of incompetent developers that would still do as such in the current year, but then this becomes a whole different argument.
- mmis1000 2y ago
  The 200kb is already an underestimate. If you search temporal date polyfill and check the js size. It's 200kb for 'single' language. Date is much more complex than you expect. And even yourself don't use it. The library authors will. There will be someday that people take the existence of temporal date api for granted. And you have no choice but import the polyfill if you want to deal with old browsers.
redman25 2y ago
Shouldn't datetime handling happen in the backend. I cannot imagine why you would trust the client to give you accurate time.
- lxgr 2y ago
  If you want to display a time you have in UTC in the user's local timezone, what other choice do you have (unless there's a way you can ask them for their timezone, but I always find that incredibly annoying when traveling)?

ravenstine 2y ago

> Either this, or every project starts with a 200kb date library import. It's interesting you say this but then go on to explain that you roll your own date library. Doesn't that discredit the idea that the alternative for every project must be a 200kb date library? I agree that most projects work with dates and time zones in some way, but that doesn't mean we'd have to use moment.js in the absence of the Date API. There's plenty of incompetent developers that would still do as such in the current year, but then this becomes a whole different argument.

mmis1000 2y ago
The 200kb is already an underestimate. If you search temporal date polyfill and check the js size. It's 200kb for 'single' language. Date is much more complex than you expect. And even yourself don't use it. The library authors will. There will be someday that people take the existence of temporal date api for granted. And you have no choice but import the polyfill if you want to deal with old browsers.

redman25 2y ago

Shouldn't datetime handling happen in the backend. I cannot imagine why you would trust the client to give you accurate time.

lxgr 2y ago
If you want to display a time you have in UTC in the user's local timezone, what other choice do you have (unless there's a way you can ask them for their timezone, but I always find that incredibly annoying when traveling)?