Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Buggz yet moment is a piece of shit. Still is the only library that handle decently local time.
If u feel like it u can always use utc methods in the date class -
@Buggz I don't like the idea of adding another dependency for one utility function.
-
@AnonymusPanther you have to. But maybe for your use case take a look at date-fns u can cherry pick function by function so you don't add any weight to your code
-
Why not store the date in UTC on the server and let the browser handle the local timezone on the client?
If you work with ISO date strings (preferably), parsing the date on the Frontend is really straightforward:
let d = new Date(isoString);
If you still work with timestamps, things like Date.now() and (new Date()).getTime() all return UTC timestamps.
What only relying on JavaScript for HTML form input validation looks like
Found something true as 1 == 1
Converting server time to any given local timezone is a pain in the ass.. at least in JS.
Here's what I've got:
convertNowToTimezone = (localOffset) => {
let d = new Date();
let millis = d.getTime() + (d.getTimezoneOffset() * 60000); //convert server local time to UTC millisec
d.setTime(millis - (localOffset * 60000)); //convert UTC millisec to required local time
return d;
}
where I pass localOffset as -330 (IST offset).
Works in chrome console but gives a diff of 4min in the server side nodejs I'm running it in..
🤬🤬😡😡😡😡😡
rant
utc time
nodejs
timezones
js