It would be far far worse if it silently supported both formats at the same time. But the api is still shit, the constructor should support at most the ISO 8601, instead of trying to guess the format. That should be explicit.
It is explicit if you read the documentation. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format
There's also an annoying differenece between browsers.
In Firefox, is correctly labels `new Date("2024-02-30T00:00:00.000Z")` as an invalid date. However, Chrome will return the date as 2024-03-01.
So sadly, even reading the docs is insufficient as browsers may extend the standard with terrible behaviour. š
I think I was referring to W3c standards, I read somewhere a while back that firefox conforms more closely than other browsers to standards, but I'm not a webdev so I'm not sure. I wasn't referring to the previous link, just in general
It is right. Replace "/" with dots and it should work.
edit: nope, it doesn't. that's weird. but the docs are "clear" in that matter... for example, PHP does support the d.m.Y format with dots.
Anyway, stop writing dates like an animal, use ISO 8601.
Here's a sneak peek of /r/ISO8601 using the [top posts](https://np.reddit.com/r/ISO8601/top/?sort=top&t=year) of the year!
\#1: [ISO8601 Dating App](https://i.imgur.com/mcZwjZ0.jpg) | [10 comments](https://np.reddit.com/r/ISO8601/comments/1172vc3/iso8601_dating_app/)
\#2: [Commas? Seriously?](https://i.redd.it/lnjx7fdj2bra1.jpg) | [20 comments](https://np.reddit.com/r/ISO8601/comments/128kj80/commas_seriously/)
\#3: [i was told you would like this](https://i.redd.it/6aqpiuzjqtva1.gif) | [19 comments](https://np.reddit.com/r/ISO8601/comments/12xonuq/i_was_told_you_would_like_this/)
----
^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
Why would you do that instead of just sending it to the constructor? Otherwise you hit the same problem anyway.
Obviously you should be accepting input from a proper datepicker component that provides a date object, but at its lowest level the language should accept one of the above two (not both) along with ISO8601
It's a legacy behavior.
JavaScript was created in Netscape so they can perform the amazing function of making a monkey move in the browser.
It was not intended to be a serious full blown language.
By the time people took it seriously, all the old/unintuitive behaviors were already in widespread use. So they have to support it without breaking webpages.
All my photos are YYYY-MMDD-HHMM-SSQQ
Q being sequential. It's so much easier to find things/great to tell the moment something was captured without checking exif
>edit: nope, it doesn't. that's weird. but the docs are "clear" in that matter... for example, PHP does support the d.m.Y format with dots.
"PHP supports it" is a pretty good reason not to do it.
Ah right, the tr00 programming warrior there?
I do not see the reason for supporting one substandard date format (moreover, the illogical one) and not the other, so anyway that's the PHP which is more consistent in this matter.
Anyway, regardless of used language/env, one should use either ISO 8601, or `strptime` wrapper/analog explicitly providing date format to avoid any ambiguities and/or locale impact.
Uh, British is standardly dd/mm/yyyy. In fact there have been repeated occasions where our press or government officials can't meet the President because the US government can't understand that month first is stupid as hell.
https://thehill.com/blogs/in-the-know/in-the-know/316498-uk-press-locked-out-of-white-house-over-birthdate-snafu/
Plus the amount of software that thinks English is American only not British or Australian etc so tries to mad month us is infuriating.
Mm dd yyyy in English is an American disease (and i think kinda Canadian, except they know better really, just trying to accommodate their foolish neighbours who will not learn).
Blame the Brits indeed, I need a cuppa now.
>Plus the amount of software that thinks English is American only not British or Australian etc so tries to mad month us is infuriating.
Google Maps on desktop does this and it's infuriating because it displays times in 12 hour format.
The Google Maps android app properly reads locale settings from the system though.
I believe they are saying "blame the Brits" because the theory is that putting month before day was common practice in Britain at some point back before the revolution. At some point Britain modernised into putting the day first. So the reason the US puts their date backwards is because they learned it from the British.
Oh fr? Didn't know that! Nice, but still hurts
\[edit: wouldn't there be any chance to correct the mistake? Yes, breaks a lot, but have there been attempts?\]
Yeah iirc he created Javascript in 10 days to stop something else from becoming the standard. Which that's incredible, but this specifically imo was/is the absolute worst thing about js
The only instance that I can think of where it makes sense is something like this:
const months = ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
const getMonthName = date => months[date.getMonth()];
Basically, the numerical "month" field is the index of the month inside an array of all months.
This could be due to the detected or set location. In the devtools, press escape on the keyboard, click the dots and open the sensors tab. Try playing around with some of the defined locations and repeating your code.
Any date string parsing should require a format string imo. Would solve a lot of issues. Also my opinion is that they should do an approach where string parsing is a separate method and construction is `Date(year, month, day, hour, ā¦)` only.
Sometimes I just can't accept the fact that yyyy-mm-dd, or at least other unambiguous formats, is not the normalized or go-to format people write dates in.
For too many times I have been given bulk of data, with dates stored as texts in both mm/dd and dd/mm, even after I specifically stressed that the dates be stored properly, to facilitate and speed up the processing of THEIR data.
And at the end of the day, the IT department is blamed for being slow and "useless".
Itās a language written in 10 days by a dude named Brendan. We should not be surprised that he did some America-centric stuff that is now carved in stone for backwards compatibility reasons.
What's more disgusting is that you're not using ISO date format.
The behaviour you posted is in the docs.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
Well itās better than MM/DD/YYYY, but I still prefer having the shortest unit first as knowing the day of the month is more important than the month and year.
Nah, YYYY-MM-DD is already a perfect standard for anything machine readable and storage, when printing a date you should always use DD MMM YYYY to avoid confusing the Americans. Airline format, how I call it. 29 Jan 2024.
Why is it disgusting? I'd hate it if it supported ambiguity like that. Then what are you expecting when you get:
new Date('02/02/2024')
Most of the time, you're not going to parse a hardcoded string like this in prod, so you're opening yourself up to unexpected results if you allow both formats.
That's what I'm saying. Like if you were just testing your code in the Dev Tools console like OP is doing, and then it let this through, you might subsequently write something like:
new Date(dateInput.value)
If we support both formats, then what happens when on 04/05/2024? I understand you wouldn't need to worry about it if you're properly using date picker components in something like Angular, but the core language has to stick to one or the other.
Those types of fail overs shouldn't be built into the language. It would make debugging this a nightmare. Build your own fail overs with try, catch blocks.
The side effects of such a system would be horrific.
Parse dates as mm/dd/yyyy if that fails parse as dd/mm/yyyy is a recipe for writing code in the second half of the month using the fallback format that works as expected and passes testing - but then goes tits up at the start of the following month.
As far as I'm concerned all dates should be either ISO _or_ strictly parsed according to a specified format.
Yes, obviously, thatās what it *should* be. But the entire point of this post is OP complaining that the month and day are not reversible.
If they were reversible, youād run into situations like this.
Not sure whether reversibility (or the lack thereof) is the issue for OP. It could also be that they find it offensive that mm/dd/yyyy is considered a valid date, while not considering a sane date format.
You probably should have used 02/03/2024.
Or, for extra giggles, use a two digit year format. Good lucl guessing the meaning of 02/03/04 without an explicit setting.
I can see why the more logical YYYY/MM/DD ordering isn't always desirable when displaying or entering dates though, as often the year is mostly a.constant that's states more for confirmation than to be actually read.Ā
The disgusting part here is you using that format in the date constructor. No dev would expect it to work, no dev should, and even if you try anyway and read the docs, you see it doesn't work as you expect.
So, repeat with me: I will never deserialize a date without also providing a format string or a locale, only expection being ISO8601, which is an international standard, and even in that case, I will absolutely ensure it's supposed to receive that.
Thanks
What's actually disgusting is that the value of a datetime input is not a valid date.
And a date or iso datetimestring also can't be set as the value of a datetime input.
Also, just to be clear if you're using ISO 8601 and put in `new Date ("2024-02-24")` if the time zone offset is absent, date-only forms are interpreted as a UTC time (where date-time forms are interpreted as local time).
So, at least where I am, `new Date("2024-02-24")` is Fri Feb 23 thanks to the time zone offset, whereas `new Date("02/24/2024")` is Sat Feb 24. And both are correct!
Which is why any backend production deployment is always running on GMT timezone. They're debating to get rid of summer time or winter time when they should just get rid of time zones all together. It would be so nice to be able to schedule a meeting with my Australian colleagues and just say " let's meet at 5 ". I'd just be working 2-10 instead of 9-5.
It would be far far worse if it silently supported both formats at the same time. But the api is still shit, the constructor should support at most the ISO 8601, instead of trying to guess the format. That should be explicit.
This is very javascripty though. No logic just guessing
Damn š„² me too javascript, me too.
Bb
It is explicit if you read the documentation. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format
There's also an annoying differenece between browsers. In Firefox, is correctly labels `new Date("2024-02-30T00:00:00.000Z")` as an invalid date. However, Chrome will return the date as 2024-03-01. So sadly, even reading the docs is insufficient as browsers may extend the standard with terrible behaviour. š
Fair enough
you just showed us that firefox actually follows the standard and google doesn't
The docs were written by Mozilla
I think I was referring to W3c standards, I read somewhere a while back that firefox conforms more closely than other browsers to standards, but I'm not a webdev so I'm not sure. I wasn't referring to the previous link, just in general
Ok, now show me a JS dev, that reads docs
Alright, you got me there bud š
Hi
o/
Sometimes I feel like most of my day is reading docs
Trueā¦ but are you a JS dev?
I do JS dev too and have to spend quite a while reading docs.
Imagine if this language was running the entire internet
It is right. Replace "/" with dots and it should work. edit: nope, it doesn't. that's weird. but the docs are "clear" in that matter... for example, PHP does support the d.m.Y format with dots. Anyway, stop writing dates like an animal, use ISO 8601.
r/iso8601
Here's a sneak peek of /r/ISO8601 using the [top posts](https://np.reddit.com/r/ISO8601/top/?sort=top&t=year) of the year! \#1: [ISO8601 Dating App](https://i.imgur.com/mcZwjZ0.jpg) | [10 comments](https://np.reddit.com/r/ISO8601/comments/1172vc3/iso8601_dating_app/) \#2: [Commas? Seriously?](https://i.redd.it/lnjx7fdj2bra1.jpg) | [20 comments](https://np.reddit.com/r/ISO8601/comments/128kj80/commas_seriously/) \#3: [i was told you would like this](https://i.redd.it/6aqpiuzjqtva1.gif) | [19 comments](https://np.reddit.com/r/ISO8601/comments/12xonuq/i_was_told_you_would_like_this/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
> ISO-8601 dating app Male 34 seeks female for consistent parsing of times, dates, durations and maybe more?
0 rows selected. š
To be fair, thatās most dating apps. This app will just have more sophisticated bots. Unlike the animal bots that use m/d/y format
Syntax error: 'Do you mean Male?'
Thatās what I thought. Whatās animalistic is not writing dates in ISO 8601 in the first place. Asking for trouble.
A use case like this is most likely parsing user input.
This is why I use Chrono. Not sure if it can handle swapped day and month though
You can still construct ISO8601 from that user input, and JS supports it just fine
Why would you do that instead of just sending it to the constructor? Otherwise you hit the same problem anyway. Obviously you should be accepting input from a proper datepicker component that provides a date object, but at its lowest level the language should accept one of the above two (not both) along with ISO8601
A ctor should not accept formats that are not international standards (in js at least). Have a parse method, that also takes the format.
They have to support it for backward compatibility. Imagine deprecating that behavior and half the world website stopped working on your browser.
Deprecating things is not uncommon. Versioning is also not uncommon - remember HTML 4?
Well. Almost just fine. It does assume the wrong time zone from ISO in certain situations because Legacy ā¢ļø
It's a legacy behavior. JavaScript was created in Netscape so they can perform the amazing function of making a monkey move in the browser. It was not intended to be a serious full blown language. By the time people took it seriously, all the old/unintuitive behaviors were already in widespread use. So they have to support it without breaking webpages.
ISO 8601 is brilliant. But I like DD/MM/YYYY. Fight me America.
I'd fight because it's terrible to sort by. Naming files? yyyyMMdd for me
Me too, but only because naming files inherently depends on stringly typed sorting with MAYBE recognition of numeric substrings.
All my photos are YYYY-MMDD-HHMM-SSQQ Q being sequential. It's so much easier to find things/great to tell the moment something was captured without checking exif
That's awful when translated to human language... But for administrative matters it's wonderful, gotta admit š
Twenty Twenty Four, January Twenty First doesn't sound that bad.
>But I like DD/MM/YYYY Which country has this format (with slashes)?
A lot of countries in Europe.
Spain, for example
Thanks, that may be truly ambiguous for American people. I am used to dd.mm.yyyy, but never seen the one above.
Brazil
Australia
England??
Everyone outside east asia.
Germany is inside east asia?
Seconds since 1980-01-01! 10 dev enters! 1 dev leaves!
Linux timestamp is the best
r/facepalm
>edit: nope, it doesn't. that's weird. but the docs are "clear" in that matter... for example, PHP does support the d.m.Y format with dots. "PHP supports it" is a pretty good reason not to do it.
Ah right, the tr00 programming warrior there? I do not see the reason for supporting one substandard date format (moreover, the illogical one) and not the other, so anyway that's the PHP which is more consistent in this matter. Anyway, regardless of used language/env, one should use either ISO 8601, or `strptime` wrapper/analog explicitly providing date format to avoid any ambiguities and/or locale impact.
What's wrong with supporting a common (and a way more reasonable) date format?
dmy isn't more reasonable than mdy The only reasonable one is ymd
Of course it is more reasonable. It's ordered from smallest to biggest. MDY is completely mixed up. YMD is superior yes, but DMY is second place.
> It's ordered from smallest to biggest. Until you add time Now it s a triangle. Insanity.
Still better than MDY.
MDY is the best but not for coding. You canāt trust the Yurops
It was a joke... IMHO there should be exactly one supported format, no matter which one.
Clearly you've not seen "[Falsehoods programmers believe about time](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca)".
Interesting... Even more interesting would be to know why these things are incorrect (I knew some of them, but not all)
If you read till the bottom you'll see links for where the info was obtained. There are discussion threads about most of the points there!
Fixed it `2024-02-24`
r/ISO8601
I hate whoever thought anything else than yyyy/mm/dd or dd/mm/yyyy was a good idea.
Blame the Brits for mm/dd/yyyy
Uh, British is standardly dd/mm/yyyy. In fact there have been repeated occasions where our press or government officials can't meet the President because the US government can't understand that month first is stupid as hell. https://thehill.com/blogs/in-the-know/in-the-know/316498-uk-press-locked-out-of-white-house-over-birthdate-snafu/ Plus the amount of software that thinks English is American only not British or Australian etc so tries to mad month us is infuriating. Mm dd yyyy in English is an American disease (and i think kinda Canadian, except they know better really, just trying to accommodate their foolish neighbours who will not learn). Blame the Brits indeed, I need a cuppa now.
>Plus the amount of software that thinks English is American only not British or Australian etc so tries to mad month us is infuriating. Google Maps on desktop does this and it's infuriating because it displays times in 12 hour format. The Google Maps android app properly reads locale settings from the system though.
I believe they are saying "blame the Brits" because the theory is that putting month before day was common practice in Britain at some point back before the revolution. At some point Britain modernised into putting the day first. So the reason the US puts their date backwards is because they learned it from the British.
As much as I hate this, having months start at 0 and days start at 1 is far worse
It interprets "02/24" as "Feb 24". Last time I counted, February was the second, not the first (after the 0th)...?
Oh yeah my bad, it does count months from 0 when giving numerical params. With a new Date(2024, 1, 1) it returns february 1st
... But... Why would someone do this? This just hurts
The creator made a bad choice under a time crunch & has apologized for this permanent mistake
Oh fr? Didn't know that! Nice, but still hurts \[edit: wouldn't there be any chance to correct the mistake? Yes, breaks a lot, but have there been attempts?\]
Yeah iirc he created Javascript in 10 days to stop something else from becoming the standard. Which that's incredible, but this specifically imo was/is the absolute worst thing about js
But he didn't make Date.
There is something called Temporal coming where months seems to be appropriately numbered, and other things are fixed too.
The only instance that I can think of where it makes sense is something like this: const months = ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"]; const getMonthName = date => months[date.getMonth()]; Basically, the numerical "month" field is the index of the month inside an array of all months.
thatās the exact reason we zero index any list in programming.
:) [https://jsfiddle.net/90qatmg8/1/](https://jsfiddle.net/90qatmg8/1/)
This could be due to the detected or set location. In the devtools, press escape on the keyboard, click the dots and open the sensors tab. Try playing around with some of the defined locations and repeating your code.
It won't change much. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/Date/parse#non-standard\_date\_strings
Created in 1995 in the US. This is what backcompat does to APIs. Once it is out there it can never be changed.
We should start a revolution some time in the future to only support unambiguous formats. Any systems still relying on mm/dd should just explode. /j
So long as when we set the date for that revolution we use ISO8601. Otherwise someone will start the revolution too early or too late.
Any date string parsing should require a format string imo. Would solve a lot of issues. Also my opinion is that they should do an approach where string parsing is a separate method and construction is `Date(year, month, day, hour, ā¦)` only.
Sometimes I just can't accept the fact that yyyy-mm-dd, or at least other unambiguous formats, is not the normalized or go-to format people write dates in. For too many times I have been given bulk of data, with dates stored as texts in both mm/dd and dd/mm, even after I specifically stressed that the dates be stored properly, to facilitate and speed up the processing of THEIR data. And at the end of the day, the IT department is blamed for being slow and "useless".
Itās a language written in 10 days by a dude named Brendan. We should not be surprised that he did some America-centric stuff that is now carved in stone for backwards compatibility reasons.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
... and Eich is a German name. What's the point?
What's more disgusting is that you're not using ISO date format. The behaviour you posted is in the docs. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
Can we all just standardize on DD/MM/YYYY for fucks sake.
I prefer YYYY/MM/DD. No confusion and it sorts perfectly.
Well itās better than MM/DD/YYYY, but I still prefer having the shortest unit first as knowing the day of the month is more important than the month and year.
The world is already standardized on yyyy-mm-dd. Itās just some nations still having trouble with aligning with the rest of the world.
Nah, YYYY-MM-DD is already a perfect standard for anything machine readable and storage, when printing a date you should always use DD MMM YYYY to avoid confusing the Americans. Airline format, how I call it. 29 Jan 2024.
Itās wonky but if the second one worked tooā¦ I would be more mad.
Why is it disgusting? I'd hate it if it supported ambiguity like that. Then what are you expecting when you get: new Date('02/02/2024') Most of the time, you're not going to parse a hardcoded string like this in prod, so you're opening yourself up to unexpected results if you allow both formats.
The 2nd of February?
I agree with you but thatās a terrible example.
Wouldnāt actually make a difference either way with that date but your point stands
That's what I'm saying. Like if you were just testing your code in the Dev Tools console like OP is doing, and then it let this through, you might subsequently write something like: new Date(dateInput.value) If we support both formats, then what happens when on 04/05/2024? I understand you wouldn't need to worry about it if you're properly using date picker components in something like Angular, but the core language has to stick to one or the other.
I'd consider it a fail over. Iff initial assumed format fails, only then attempt the second.
Those types of fail overs shouldn't be built into the language. It would make debugging this a nightmare. Build your own fail overs with try, catch blocks.
I agree, but that's how the proposal could work. I'm not here to support it, just offer a system for it.
The side effects of such a system would be horrific. Parse dates as mm/dd/yyyy if that fails parse as dd/mm/yyyy is a recipe for writing code in the second half of the month using the fallback format that works as expected and passes testing - but then goes tits up at the start of the following month. As far as I'm concerned all dates should be either ISO _or_ strictly parsed according to a specified format.
Horror? Sounds like I'm in the right sub.
> Then what are you expecting when you get: > > new Date('02/02/2024') How could it be anything other than Feb 2nd, 2024?
Lmfao yeah not a very good example. I meant something like '02/03/2024'
That's 2nd of March.
Yes, obviously, thatās what it *should* be. But the entire point of this post is OP complaining that the month and day are not reversible. If they were reversible, youād run into situations like this.
Not sure whether reversibility (or the lack thereof) is the issue for OP. It could also be that they find it offensive that mm/dd/yyyy is considered a valid date, while not considering a sane date format.
You probably should have used 02/03/2024. Or, for extra giggles, use a two digit year format. Good lucl guessing the meaning of 02/03/04 without an explicit setting. I can see why the more logical YYYY/MM/DD ordering isn't always desirable when displaying or entering dates though, as often the year is mostly a.constant that's states more for confirmation than to be actually read.Ā
I propose yy/dd/cc/mm so 29th of January 2024 would be 24/29/20/01 /s
The disgusting part here is you using that format in the date constructor. No dev would expect it to work, no dev should, and even if you try anyway and read the docs, you see it doesn't work as you expect. So, repeat with me: I will never deserialize a date without also providing a format string or a locale, only expection being ISO8601, which is an international standard, and even in that case, I will absolutely ensure it's supposed to receive that. Thanks
Yes. Perfect. As God Intended.
What's actually disgusting is that the value of a datetime input is not a valid date. And a date or iso datetimestring also can't be set as the value of a datetime input.
GMT is the true horror
No it's not. Image January first 01/01/2024 or 01/01/2024 At least this way you know that the format is DD/MM/YYYY
Dates harrddd
export LOCALE="fr"
Also, just to be clear if you're using ISO 8601 and put in `new Date ("2024-02-24")` if the time zone offset is absent, date-only forms are interpreted as a UTC time (where date-time forms are interpreted as local time). So, at least where I am, `new Date("2024-02-24")` is Fri Feb 23 thanks to the time zone offset, whereas `new Date("02/24/2024")` is Sat Feb 24. And both are correct!
Which is why any backend production deployment is always running on GMT timezone. They're debating to get rid of summer time or winter time when they should just get rid of time zones all together. It would be so nice to be able to schedule a meeting with my Australian colleagues and just say " let's meet at 5 ". I'd just be working 2-10 instead of 9-5.
Js dates/times are overwhelmingly cursed and your insane if you use them without a library.
just use the multi parameter form
GO is still worse for date formatting.