Khaled: Could you give us an exhaustive list of primary date/time formats accepted as input to $ctime(), and then discuss the minor variations or deviations that will also be detected and accepted for each type? (It would assist me in framing the boundaries of this bug.)
The help file specifies the following four formats are recognized:
January 1 1970 00:00:00
3rd August 1987 3:46pm
21/4/72 1:30:37
Wed 1998-3-27 21:16
Of these formats, the user can deviate by omitting certain portions, such as the time (h:m:s) so that the current clock-time is assumed.
We can also see that these formats work:
3 Aug 1987 /* a variation of 3rd August 1987 3:46pm */
1998-03-27 /* a variation of Wed 1998-3-27 21:16 */
Are you using conventional C++ string array parsing, or regular expression parsing? If regular expression parsing, would you share the regex patterns with us?
If I were better informed of the different standard ISO date-time formats, I could articulate this post better, but I'm not there yet.
Also, did we arrive yet at a consensus to recognize $gmt(n) or $gmt($ctime(<date>)) as acceptable use of $gmt()? ((i think it should be))
---
One minor suggestion for added support for date-time recognition and assumption-making in $ctime():
If only a time value is passed, but no date value, then assume the current date. As in $ctime(13:00:59) or $ctime(5:00 p.m.) Below is pseudo-code.
This is similar in behavior to how $ctime() handles a date value with no time value, just in reverse, as it assumes the current time instead.
if ($regex($1-,/^[0-9:apm. ]+$/i)) { tokenize 32 $date $1- }
