if you treat is as "text", you can use the Left(), Right() & Middle() functions to get the values. You also need to test for two-digit or four-digit year.
[ mydate = "15111989"
; da = Left(mydate; 2)
; mo = Middle(mydate; 3; 2) // start with 3rd char and get two chars
; yr = Middle(mydate; 5; 4) // start with 5th char and get 4 chars
// note! this will get up to 4 characters for the year, so will get 2 or 4
; result = GetAsNumber(mo) & "/" & GetAsNumber(da) & "/" & yr
]; result // return the concatenated text
NOTE! this means that single-digit months and days will not calculate correctly. So you must train your users to pad with 0 on input. And that may not be to their liking.
I can't let a question relating to date formatting go by without calling attention to ISO 8601, the international standard for date formatting. In particular, the standard calls for 4-digit years (for example, "1989", not just "89"), to avoid hard-coding the sort of content-impoverished date info that caused so many programmers to have to work so hard toward the end of the 20th Century to stave off unexpected disasters due to the Y2K problem. ISO 8601 had provided a clear, logical way to avoid that problem as far back as 1988, and it would have prevented a lot of headaches if people had only started using it right away. But they preferred to coast along with 2-digit years, "because we've always done it this way," until it was nearly too late. It was then, and still is today, a lesson well worth learning.
true, RR! I prefer dates like: yyyy-mm-dd because they are alpha-sortable, and cross country boundaries.
BTW, This topic should not be "product issue", but discussion (or question).
As the Author, you find a option "move to …" on the right side in the section Actions.
Just a silly questions:
- would it be too much to ask the user to use 'dot' separation for input? [15.11.1988]
I can even write '15.11.88' into a date field and FMP stores as '15/11/1988'
- am I missing something?
If you have 3 separate fields for year, month, and day, you can thereafter separate them using any characters you want. Furthermore, you can apply validity checks to each of them separately (for example, days must be from from 1 to 31, months from 1 to 12, everything numeric, etc.) Or you don't have to separate them at all. You could treat today, for example, as 20160704. I do it all the time.
beverly, you are spot on.
- I'm not sure what happened, when I posted the question.
The clients are using "/", and not "." dot, as the dot is not available on the numerical side of the keyboard.
- Ye, Danish/EU keyboard layout, wuhu!
I'm not quite sure I want to do that, since it's an old database.
The way I read it, what I am searching for a date-field, isn't possible.
Making a date-field more or less 'free' to write in, based on ISO 8601 standards.
Saying 15111989, the date field should set "/" or "." based on a script trigger or custom function, when exiting the date-field..?
If you have your clients enter the date components, you can use them to create a calculated date field, which you can then format any way you want. The component approach means that you don't have to bother them with details about leading zeroes or what kind of separator character to use. And you can use the calculated field for whichever of your Find operations need to look for specific dates, while relying on the components to Find, say, specific years.
Discussions of computerized dates and the Y2K problem remind me of this decade-old joke (or is it a joke?):
All coders know that the boringest work in their field is maintenance programming, and no computer language is more tedious than COBOL. In the runup to the year 2000, one guy had been doing that and nothing else for several years in an effort to find and squash potential Y2K bugs before they could cause various problems of unknown magnitude. He finally got so sick of it he decided to have himself frozen, to be thawed out only a couple of years later, by which time it would be all over.
Upon his revival, he found himself in a strangely appointed room, facing several nervous people in outlandish outfits. In oddly accented English, one of them informed him that there had been a lot of mixups in electronic records of dates “way back then”, that somehow his defrosting date had gotten scrambled, and that he had inadvertently been left in cryogenic storage for 8000 years. “I’m sorry to have to tell you that everyone you ever knew is long dead.”
After he got over the shock and had calmed down somewhat, it dawned on him to ask what had prompted them to bring him back after so many years.
Again there was an awkward silence before one of them said, “Well, we’re coming up on the year 10,000, and according to your records, you know COBOL ....”