{{tag>category:"OpenInsight" author:"Oystein Reigem" author:"WinWin/Revelation Technical Support" author:"[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]" author:"Richard Bright" author:"Ray Chan" author:"Mark Glicksman"}} [[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]] ==== Date validation and conversion (OpenInsight) ==== === At 14 SEP 2000 04:45:49AM Oystein Reigem wrote: === Is the source for the Revelation date validation and conversion available? Or is there at least a documentation of valid syntax? It's the DE validation and D.E conversion I'm interested in, nothing else. The reason for my interest: In my new app I need a [i]flexible[/i] date field - one that both accepts normal dates and some variations. To be more specific: My extended date field must be able to accept both specific dates ([i]year+month+day)[/i] and less precise indications of time, i.e, just [i]year+month[/i] or [i]year[/i] alone. If I had the source I could extend it to cover the variations. Without any source and documentation I have to do a lot of experiments to be sure I cover everything the standard validation and conversion does. I've discovered some amazing formats the standard DE validation accepts. E.g [i]14 September (or is it October already?) 2000 Jan killed 1 rabbit and I killed 2 June read Catch 22 before having 69 Jan failed on her maths test because she said the square root of -4 is -2[/i] Well, my aim isn't really to get my UDC to accept crazy syntax like that. The reason I need to know is... ...uh... ...it's because... ...um... ...just trust me, will you! :-) (Btw - I cannot store such data in the Revelation internal date format. Instead I think I will use something similar to the external D.E format, e.g, [i]28.11.1953 .11.1953 ..1953[/i]) - Oystein - ---- === At 14 SEP 2000 08:37AM WinWin/Revelation Technical Support wrote: === Oystein- The source is not available, nor is it planned to be made available through the CSP. It's not that it's super secret or anything, it's that OCONV is written in MetaCode. Can you use something like the following as a start- It accepts dates or N/A. Hope it helps- Mike Ruane *----------------Code Starts Here ---------------- compile SUBROUTINE NA_Date( charstr CONV, charstr ANS, charstr BRANCH, charstr RETURN_DATA) * * This subroutine should be used as the first and only "Input Validation" in * a window prompt. Placed in "Output Format", it properly formats any * reasonable string of numbers into a consistent US telephone number format. * * Subroutine declarations $insert msg_equates declare function msg * Local Equates * The STATUS() variable is used to indicated the error condition of the * pattern. They are: EQU VALID$ TO 0 ;* Successful EQU INVALID_MSG$ TO 1 ;* Bad Data - Print error message window EQU INVALID_CONV$ TO 2 ;* Bad Conversion - " " EQU INVALID_NOMSG$ TO 3 ;* Bad but do not print the error message window EQU THREEDGRAY$ TO 192 * Begin Conversion * RETURN_DATA=" IF ANS NE "" THEN TEst=ANS STATUS()=VALID$ convert @lower.case to @upper.case in test if test=N/A' then return_data=test End Else IF CONV EQ "OCONV" THEN RETURN_DATA=oconv(test,'D4/') END ELSE CONVERT '-/\.' TO ' ' IN TEST TEST=TRIM(TEST) YY=FIELD(TEST,' ',3) IF YY=' THEN YY=OCONV(DATE(),'D2/')-2,2 TEST:= ' ':YY End OTEST=ICONV(TEst,'D4/') IF Len(OTEST) THEN RETURN_DATA=OTEST END ELSE MESS=' MESS=The data must be a valid date in the format:' mess=mess :'|Month Day Year' mess=!' mess=Data Validation Error" x=msg('',mess) STATUS()=INVALID_NOMSG$ END END End End RETURN * ---- === At 14 SEP 2000 09:31AM Oystein Reigem wrote: === Mike, [i]Can you use something like the following as a start[/i] Yes and no. That "N/A" case is easy because it's so different from every possible date input. My month+year case, on the other hand, looks too much like valid standard syntax. E.g - what is "9.9"? Day 9 of month 9 of the current year according to standard DE validation. But in my case it could also mean Month 9 of year 2009. "13.9" and "9.13" are easier, but need some inspection first. But it's good with another programming example, and there are a couple of details I'll bring with me in my own UDC. - Oystein - ---- === At 14 SEP 2000 02:37PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote: === [notag]Actually, truth be told, most of OCONV is actually implemented in the ASM as part of the opcode. It only jumps to RBASIC if it's one of the few types that the opcode can't handle. These were scientific notation, the combined datetime, g-correlatives, user defined conversions, the Uxxx codes and bolean. The meta simply parsed out the commands and placed it into a standard format to make it ready for an on-gosub or something like that. Some of the new things ended up in the rbasic code as well, but it just did some simple formatting before re-calling the opcode again. The curse of remembering every line of code one's worked on. [The Sprezzatura Group] [World Leaders in all things RevSoft] [] [] [
] [/notag] ---- === At 14 SEP 2000 02:53PM Oystein Reigem wrote: === That's a curse I'm not blessed with. It's not so long ago I made the same utility for a client twice. He requested a utility with a certain functionality. I spent a few hours making it. I mailed it to him. He forgot to use it. He forgot he'd got it. He asked me again. I spent another few hours making a new version. Not until I put in the final touches did I realize I'd done the same job a couple of months back. Duh. - Oystein - ---- === At 14 SEP 2000 06:19PM Richard Bright wrote: === I have used a internal format for date like Rev_Internal_Date|Display_Value Where display value takes a value which determines how to present the precision of the date - ie day/month/year or month/year or year or decade etc. This has allowed me to then have a UDC which allows handling of date ranges MIXED with dates of various precisions. Yup UDC are VERY useful. Richard Bright ---- === At 14 SEP 2000 09:00PM Ray Chan wrote: === Oystein, [i]I spent a few hours making it...He forgot to use it. He forgot he'd got it. He asked me again. I spent another few hours making a new version. Not until I put in the final touches did I realize I'd done the same job a couple of months back. Duh.[/i] You could say the same about me. But what really worries me is that I do this without the benefit of "Pauwel Kwak". It seems to come naturally. I'm now forcing myself to write things down! Ray ---- === At 15 SEP 2000 03:10AM Oystein Reigem wrote: === Ray, But I'm a natural too. Did it without a drop of Kwak. Honest!! - Oystein - ---- === At 15 SEP 2000 04:03AM Oystein Reigem wrote: === Richard, Well, it's comforting to hear I'm not alone. Sometimes while pondering these crazy dates with varying precision (DVPs for short) I've wondered if I was crazy too. :-) [i]I have used a internal format for date like Rev_Internal_Date|Display_Value ... ... ...[/i] I think I can see the advantages with that approach. But as said earlier I think I will [i]not[/i] store the internal Revelation date format but rather use sort of a modified external D.E format: [i]28.11.1953 .11.1953 ..1953[/i] (That's my birthday, by the way.) :-) Then I'll have a couple of symbolics for sorting and searching. For sorting and searching one needs precise values. What I'll do is first regard each DVP value as a range: [i]28.11.1953[/i] is [i]28.11.1953 - 28.11.1953[/i] [i].11.1953[/i] is [i]1.11.1953 - 30.11.1953[/i] [i]..1953[/i] is [i]1.1.1953 - 31.12.1953[/i] Then I'll have one symbolic for each end of the range. [i]These range values[/i] will be internal Revelation dates. I may also create an additional symbolic for sorting - a precision code (1=y, 2=m+y, 3=d+m+y). But the range values should be enough, really. I can now get a useful (ascending) sort order by sorting on and . Or and descending on . And I can search on a date X with (X GE ) AND (X LE ). - Oystein - ---- === At 15 SEP 2000 12:08PM Ray Chan wrote: === Oystein, We're naturally "talented" . Hey I'll drink to that. Hick..hick. Ray ---- === At 18 SEP 2000 10:20AM Mark Glicksman wrote: === I store the date and accuracy in a plain text format like this: "13 NOV 1934 | D" (exact date), "NOV 1934 | M" (month), "1934 | Y" (year), "1934 | U" (year of unknown accuracy) , and "1934-1936 | R" (range of years). I use symbolic fields for sorting and searching. For data entry, I use a right-click popup dialog box that allows the user to enter the date with the desired accuracy and formats the input accordingly. glicks@compuserve.com [url=http://www.bg-map.com]BG-Map Botanical Garden Mapping System [img]http://www.bg-map.com/bgmap.gif[/img][/url] ---- === At 19 SEP 2000 06:51AM Oystein Reigem wrote: === Mark, Thanks. Good to hear about others' experiences and solutions with fuzzy dates. You haven't said how you search on your U years. E.g, will a search on 1909 find 1910|U? I see you have explicit ranges too, not just the ones implicit in values with a M or Y accuracy. The specs I'm developing according too have such explicit ranges as well. The drafts of the specs docs really went over the top, rangewise: First, events in a museum object's life can take place over a period of time - not just a point in time. So one needs a start date and an end date. E.g an artist worked on a painting over a period of 10 years 1910-1920. This isn't really about accuracy. But the result is you need 2 dates. Then, one isn't always certain of these dates. E.g, with the painting above one is not quite sure it was 1910 the artist started his work. It might have been as early as 1909, but not later than 1912. Similarly with the end date. So now each end point becomes a range as well. I.e, 4 dates. (But we (developers) hope the final version of the specs will say 2 is enough.) Finally, since there is an implicit range in M and Y dates, each of the 4 dates is really a range in itself. I.e, 8 dates. Reminds me of an episode of the British Smack the Pony series where these two girls advertise for "blokes" on a TV dating program. Seen that? :-) - Oystein - ---- === At 19 SEP 2000 03:32PM Mark Glicksman wrote: === Oystein, Handling searches for the U accuracy is a bit problematic - I haven't really gotten into that yet. One option would be to select for year (1910 and D, M or Y accuracy) or (years 1909 - 1911 and U accuracy) etc. Our needs are really quite similar - my appication involves biographical, historical, and archaeolgical data, and there are numerous fields that require start and end dates. Setting up the querying portion of the application will be interesting indeed. Best wishes, Mark glicks@compuserve.com [url=http://www.bg-map.com]BG-Map Botanical Garden Mapping System [img]http://www.bg-map.com/bgmap.gif[/img][/url] ---- === At 25 SEP 2000 02:53PM Oystein Reigem wrote: === Mark, Perhaps the user should be allowed to set the range of uncertainty in the search interface. E.g if he specified a slack of 1 year, a search of any of the years 1909-1911 would find U 1910. E.g with 5 years, any of 1905-1915 would find U 1910. Btw - one must also consider that old dates (U years) are in general less reliable than newer ones. - Oystein - [[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=3F5FD92ED48B975F8525695A00302403|View this thread on the Works forum...]]