This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.


For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.

Validating a date

Help for those learning Tcl or writing their own scripts.
Post Reply
User avatar
arfer
Master
Posts: 436
Joined: Fri Nov 26, 2004 8:45 pm
Location: Manchester, UK

Validating a date

Post by arfer »

I'm using the following to try to validate a date in the normal US form m?m/d?d/yy (by validate I mean assertain if such a date could exist) :-

Code: Select all

if {[catch {set from [clock scan $date]} {
  # error code
} else {
  # remainder of code
}
I fully expected that an invalid date such as 13/33/10 would be caught by the above code.

My Eggdrop running Tcl 8.5 functions as I expected. Using similar code in the partyline yields :-

[20:12] <arfer> .tcl set from [clock scan 13/33/10]
[20:12] <Baal> Tcl error: unable to convert date-time string "13/33/10"

My Windrop running Tcl 8.4 does not function as expected, yielding the following in the partyline :-

[20:11] <arfer> .tcl set from [clock scan 13/33/10]
[20:11] <osmosis> Tcl: 1296604800

I'm not sure if this a Tcl version issue or a Windows/Linux date/time issue or even a geographical issue or a combination thereof.

In any event, what (hopefully simplistic) code is recommended for validating dates that functions as expected irrespective of the bot type, Tcl version, operating system or geography.
I must have had nothing to do
User avatar
Sir_Fz
Revered One
Posts: 3794
Joined: Sun Apr 27, 2003 3:10 pm
Location: Lebanon
Contact:

Post by Sir_Fz »

Not sure if Tcl is affected by the regional settings of the running machine, but if so it could be that the date format on the latter machine is not %m/%d/%y.

After a quick Google search, I found this. You can try and and see if it's correct and then modify it to suite your needs.
User avatar
speechles
Revered One
Posts: 1398
Joined: Sat Aug 26, 2006 10:19 pm
Location: emerald triangle, california (coastal redwoods)

Re: Validating a date

Post by speechles »

Arfer, are you sure you don't have that backwards? Tcl 8.5 should accept the bogus date and return a bogus value, while tcl8.4 should return the "unable to convert date/time string" reply.

Clock was changed in tcl8.5, see here.
<speechles> .tcl set a [catch {set b [clock scan 1/1/10]}]
<sp33chy> Tcl: 0
<speechles> .tcl set a [catch {set b [clock scan 33/1/10]}]
<sp33chy> Tcl: 1
<speechles> .tcl set from [clock scan 13/33/10]
<sp33chy> Tcl error: unable to convert date-time string "13/33/10"
<speechles> .tcl set test [clock scan 1/1/37]
<sp33chy> Tcl: 2114409600
<speechles> .tcl set test [clock scan 1/1/38]
<sp33chy> Tcl error: unable to convert date-time string "1/1/38"

Code: Select all

<sp33chy> I am sp33chy, running eggdrop v1.6.17: 25 users (mem: 1481k).
<sp33chy> Online for 9 days, 01:26 (background) - CPU: 34:44 - Cache hit: 9.6%
<sp33chy> Admin: jesus
<sp33chy> Config file: eggdrop.conf
<sp33chy> OS: CYGWIN_NT-5.1 1.5.18(0.132/4/2)
<sp33chy> Tcl library: /cygdrive/f/windrop/lib/tcl8.4
<sp33chy> Tcl version: 8.4.11 (header version 8.4.11)
A problem in the future will be that 32bit systems wont like the year 2038 very much.. ;)
User avatar
arfer
Master
Posts: 436
Joined: Fri Nov 26, 2004 8:45 pm
Location: Manchester, UK

Post by arfer »

Sorry, yes you are correct speechless :-

[00:34] <arfer> .tcl set test $tcl_platform(os)
[00:34] <Baal> Tcl: Linux
[00:35] <arfer> .tcl set test $tcl_version
[00:35] <Baal> Tcl: 8.4
[00:35] <arfer> .tcl set test [clock scan 13/33/10]
[00:35] <Baal> Tcl error: unable to convert date-time string "13/33/10"

[00:32] <arfer> .tcl set test $tcl_platform(os)
[00:32] <osmosis> Tcl: CYGWIN_NT-6.0
[00:32] <arfer> .tcl set test $tcl_version
[00:32] <osmosis> Tcl: 8.5
[00:33] <arfer> .tcl set test [clock scan 13/33/10]
[00:33] <osmosis> Tcl: 1296604800

In view of the pending 32 bit issue, I'm not entirely sure if it is a bright side :) or a not so bright side :( but I probably won't get to see 2038.

Thanks for the site Sir_Fz, I'll devise something along those lines most probably (that is one mean looking regexp).
I must have had nothing to do
Post Reply