From: Dean P. <pow...@ya...> - 2004-01-21 20:32:31
|
Hi, Scott: No need to worry, I've been a COBOL programmer myself for the past twelve years, so I can agree with everything you've said. The fact that business requires exacting date calculation routines is one of the reasons I chose to implement a date module first. It's a good thing you mentioned intrinsic functions, though, because I simply hadn't thought of them (In every shop I've worked in, either the compiler outright didn't support them, or the compiler may have supported them but for whatever reason their use was frowned on). I'll try and suss out what date functions TC does/does not support. My "datecal" module is still being designed, but so far I figure I'll add: - Conversion between various date formats. Plug a date into DATE-IN, tell datecal what format you're putting in and what format you want out, and the correctly formatted date will be returned. I see the following formats being supported: yymmdd/ccyymmdd mmddyy/mmddccyy ddmmyy/ddmmccyy ccyyddd (long-style Julian, ddd is the day-of-year) yyddd (tradition Julian) Note the lack of separators between the various fields that normally have them. Would anyone/everyone prefer to see these (optionally) put back in? In addition, I'd like to be able to put in any of the above date formats and tell datecal that I'd like a full date returned in the form: mmm dd, ccyy (Jan 15, 2004) DOW mmm dd, ccyy (Wed Jan 21, 2004) I've had to write both of the above date formats on reports in various shops, and having a black-box routine to do the formatting for me was a godsend. In addition, I see datecal performing the following calculations: - Add x days to a given date (x can be negative) - Add x months to a given date - Add x years to a given date (i.e. adding 1 year to 2004-02-29 should yield 2004-03-01) - Calculate # of days between two dates Of course, datecal will pass back a return value which will indicate success or failure of the routine. Possible reasons for failure would be passing in an invalid date (i.e. 1900-02-29, since 1900 was *not* a leap year, or passing in 2004-04-31, etc) or requesting an unsupported date format. In this way, datecal can also serve as a date validation routine. I think that will do it for now, but if anyone has anything else they'd like to see put in, let me know. The long date formats above open up a can of worms (internationalization, anyone?) that probably should be addressed sooner rather than later. It would be nice to have datecal know what your default preferred date format is, and more importantly what language you'd like the full month/day returned in. I've only ever worked in English language-only environments, so any ideas on how to implement this would be nice. As a last point, I'll let everyone know that over the past few years, I've been working on a COBOL specific programmer's editor. Check out http://www.clockwork-technologies.ab.ca/products.html . For now, it only works on MS-Windows, but if there's sufficient interest, I'll look at creating a Linux version of it. The code is open-source freeware, released under the terms of the GPL. Anyone is free to use it and give whatever feedback they'd like. Regards, Dean Scott Ball <sm...@ve...> wrote: Dean, Good date routines are critical. COBOL is used primarily for business applications and business applications almost always take time into consideration. [snip] By the way, what date functions are you planning on implementing and what will they do? Scott --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes |