This release sets the shebang to Bash.
Better handling of user input, bug fixes.
Fix: Inconsistent handling of base-10 arithmetic with negative and leading zeroes user input. #1
Fixes and improvements when handling user input with leading zeroes, and negative years.
Much improved handling of user dates that are in UNIX format, such as "@009000", and even "@-09000". This improves how our shell code process the UNIX dates with shell built-ins. But this update should also improve working with the C-code date wrappers when processing the user input format to ISO.
Fail gracefully when C-code date exits with error when processing user input out of their range of calculation, and fallback to the shell-built-in-only calculation code.
Fix a bug in friday-13th fun. Bash exported the modified $IFS to subshells and that was interfering with a variable expansion in the get_timef() function, so we just reset $IFS before calling the get_timef() function (bash-only).
Reduce the use of some Ksh globs, (and bash extended globbing). This may improve these small operations a little in performance.
Add Bold Colouring to some of the main function output headers (only when stdout is free).
Remove the debugf() fun from the main script and move it to the /tests directory. Probably, few people would need or know to use this piece of code other than me.
Making the code to process the user input as a best-effort basis instead of adhering to trusting absolute format correctness in user input (or rejecting it!) will make the script run slower. It will be slower from about 8% (bash) to ~38% (ksh), but this is the best code compromise.
Zsh creator writes in his Zsh guide that being a little lax about user input is a godo thing, and it is... But when we are working with three different shells, it is true to me now that if your priority is speed, one day a compromise of speed vs compatibility will have to be made nonetheless.. Even though we tried using the most basic and old shell code constructs, it does not mean some subtleties will not show up in performance when we get at it..
So, yeah. Any bigger project would have it better to stick to one modern shell only, so improvements for that shell accent can be figured out without speed compromises in other parts / interfaces of the project.. Also, that makes life much easier to fix bugs!
However, with datediff.sh script, if I would not make these code changes, then we would be having a shortcut from the standard ISO-8601 and UNIX standards, anyway.. SO it is not just a question of speed, but rather trying to reach official standards.
This fixes GitHub Issue #1.
