Could be a bug but the more likely explanation is that the field doesn't update until you try to leave it. So you put in a wrong date first, try to leave the field, get error message, then type in valid date and save a pic before leaving the field.
Or it expects the user to be 18 and has an awful error.
Ding ding, this is the likely answer. I've seen this exact issue before on multiple sites and services, and it's always been found that the form expects 18+.
Or they check for MM/DD/YYYY but prompt for DD/MM/YYYY.
Both of these are incorrect. YYYY-MM-DD for life.
This post is approved by the ISO-8601 gang.
For all of the people who like their files to be in chronological order.
...along with calendar weeks being entire weeks, not bullshit like 5 days of CW 53 and 2 of CW 1. This matters when dealing with BI facts that continue through NYE.
Do you know how infuriating it is to view analytics by calendar week with two major dips around new year's because the week is split in two?
Bonus points: "Sure, you can set the week aggregation to consider weeks starting with Monday, but if you filter for the last X calendar weeks, you'll have the last week's sunday omitted from the stats and an orphaned Sunday before the first week yoh actually wanted."
Support international standards, you bloody imbeciles.
I am intimately familiar with issues like this. It's maddening.
Or it checks for the one without spacing and doesn't remove the whitespace.
Do we have a community yet for IAm14AndThisIsFunny?
Another possible case no one seems to have mentioned. That the CSS doesn't do that kind of spacing automatically, and that the user manually put in spaces this creating an invalid date for the lulz.
Still software gore. Spacing should not matter, proper parsing should ignore whitespace in a simple format like this.
It also shouldn't require leading zeros
Even better, the appropriate spacing/symbols should be automatically added so the user doesn’t have to worry if the form is going to parse whitespace.
Even better, it should ignore all input except 0-9 so it doesn't matter if you try to put spaces or other characters.
Maybe it's for something 18 and up? Like a banking app
Remind is a communication platform that reaches students and families where they are and supports learning wherever it happens.
There was nothing in the post indicating what app this was and "Remind" is a generic enough word, even if upper-cased, to make the service not obvious. It could be a porn-site for what we know, in which case that date should naturally be rejected.
I'm going to guess they typed 02/17/2008 the first time to denote Feb 17th as is fairly standard with American apps. It then told him it was invalid because there arent 17 months in a year because it was the wrong format. They typed it correctly after and took a screen shot before pressing submit. (Making it so the error was still on screen from the previous bad submission. )
That is all just a guess though.
13 and up due to COPPA if this is a US based website.
A screenshot from the setup of the Remind mobile application with an image of a calendar and the text
"What is your birthday?
This will stay private to you and will help keep Remind safe
Birthday
DD/MM/YYYY"
Followed by a text field that has been filled out with the date "17 / 02 / 2008".
Below the text field is the red error text reading "Please enter a valid date"
[I am a human, if I’ve made a mistake please let me know. Please consider providing alt-text for ease of use. Thank you. 💜]
I think it’s using the daft American date system of m/d/y
But it says 'DD/MM/YYYY' just above the input field
EDIT: it's very possible that the input field library they use uses the American date format by default and they didn't change it...
it's very possible that the input field library they use uses the American date format by default and they didn't change it...
Dev: But it works fine on my system!
I'm happy that I taught the BA and project lead learned how to clear all site data for the application I work on. It has reduced the huge amount of
"the issue is still there!"
"Clear the cache"
"It works now"
And yes, I know I should be using something that notifies the browser to invalidate its cache. I'll add it to my mile long list of tickets.
The only thing worse than mm/dd/yyyy is dd/mm/yyyy. Use a bloody different separator if you're writing dates correctly.
What wrong with /
It's already in use for mm/dd/yyyy. When I see slashes I expect that, when I see dots I expect dd.mm.yyyy, when I see hyphens I expect yyyy-mm-dd.
And then comes along a random I guess Canuck and writes something totally incomprehensible.
it's already in use for mm/dd/yyyy
No, it's already in use for dd/mm/yyyy. When the majority of the world sees slashes (with the four-digit year at the end), they expect that. Americans are the ones making things ambiguous.
Could be a bug but the more likely explanation is that the field doesn't update until you try to leave it. So you put in a wrong date first, try to leave the field, get error message, then type in valid date and save a pic before leaving the field.
Or it expects the user to be 18 and has an awful error.
Ding ding, this is the likely answer. I've seen this exact issue before on multiple sites and services, and it's always been found that the form expects 18+.
Or they check for MM/DD/YYYY but prompt for DD/MM/YYYY.
Both of these are incorrect. YYYY-MM-DD for life.
This post is approved by the ISO-8601 gang.
For all of the people who like their files to be in chronological order.
...along with calendar weeks being entire weeks, not bullshit like 5 days of CW 53 and 2 of CW 1. This matters when dealing with BI facts that continue through NYE.
Do you know how infuriating it is to view analytics by calendar week with two major dips around new year's because the week is split in two?
Bonus points: "Sure, you can set the week aggregation to consider weeks starting with Monday, but if you filter for the last X calendar weeks, you'll have the last week's sunday omitted from the stats and an orphaned Sunday before the first week yoh actually wanted."
Support international standards, you bloody imbeciles.
I am intimately familiar with issues like this. It's maddening.
Or it checks for the one without spacing and doesn't remove the whitespace.
Do we have a community yet for IAm14AndThisIsFunny?
Another possible case no one seems to have mentioned. That the CSS doesn't do that kind of spacing automatically, and that the user manually put in spaces this creating an invalid date for the lulz.
Still software gore. Spacing should not matter, proper parsing should ignore whitespace in a simple format like this.
It also shouldn't require leading zeros
Even better, the appropriate spacing/symbols should be automatically added so the user doesn’t have to worry if the form is going to parse whitespace.
Even better, it should ignore all input except 0-9 so it doesn't matter if you try to put spaces or other characters.
Maybe it's for something 18 and up? Like a banking app
There was nothing in the post indicating what app this was and "Remind" is a generic enough word, even if upper-cased, to make the service not obvious. It could be a porn-site for what we know, in which case that date should naturally be rejected.
I'm going to guess they typed 02/17/2008 the first time to denote Feb 17th as is fairly standard with American apps. It then told him it was invalid because there arent 17 months in a year because it was the wrong format. They typed it correctly after and took a screen shot before pressing submit. (Making it so the error was still on screen from the previous bad submission. )
That is all just a guess though.
13 and up due to COPPA if this is a US based website.
https://www.ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa
Just want to say that DD/MM/YYYY is the superior date format. 💪🗓️
ISO 8601 forever!!!!!
Ever heard of ISO?
yyyy-mm-dd is even better but dd-mm-yyyy is still good
Yet still inferior to YYYY/MM/DD.
I don't understand. OP can you help?
It's likely the birthday is being rejected for not meeting minimum age to consent to the TOS.
Image Transcription:
A screenshot from the setup of the Remind mobile application with an image of a calendar and the text
"What is your birthday?
This will stay private to you and will help keep Remind safe
Birthday
DD/MM/YYYY"
Followed by a text field that has been filled out with the date "17 / 02 / 2008".
Below the text field is the red error text reading "Please enter a valid date"
[I am a human, if I’ve made a mistake please let me know. Please consider providing alt-text for ease of use. Thank you. 💜]
I think it’s using the daft American date system of m/d/y
But it says 'DD/MM/YYYY' just above the input field
EDIT: it's very possible that the input field library they use uses the American date format by default and they didn't change it...
Dev: But it works fine on my system!
I'm happy that I taught the BA and project lead learned how to clear all site data for the application I work on. It has reduced the huge amount of
"the issue is still there!"
"Clear the cache"
"It works now"
And yes, I know I should be using something that notifies the browser to invalidate its cache. I'll add it to my mile long list of tickets.
The only thing worse than mm/dd/yyyy is dd/mm/yyyy. Use a bloody different separator if you're writing dates correctly.
What wrong with /
It's already in use for mm/dd/yyyy. When I see slashes I expect that, when I see dots I expect dd.mm.yyyy, when I see hyphens I expect yyyy-mm-dd.
And then comes along a random I guess Canuck and writes something totally incomprehensible.
No, it's already in use for dd/mm/yyyy. When the majority of the world sees slashes (with the four-digit year at the end), they expect that. Americans are the ones making things ambiguous.
Then, fine, make the yanks use another symbol.