| View previous topic :: View next topic |
| Author |
Message |
arfer Master

Joined: 26 Nov 2004 Posts: 436 Location: Manchester, UK
|
Posted: Wed Jan 27, 2010 4:28 pm Post subject: Validating a date |
|
|
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: |
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 |
|
| Back to top |
|
 |
Sir_Fz Revered One

Joined: 27 Apr 2003 Posts: 3793 Location: Lebanon
|
Posted: Wed Jan 27, 2010 4:43 pm Post subject: |
|
|
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. _________________ Follow me on GitHub
- Opposing
Public Tcl scripts |
|
| Back to top |
|
 |
speechles Revered One

Joined: 26 Aug 2006 Posts: 1398 Location: emerald triangle, california (coastal redwoods)
|
Posted: Wed Jan 27, 2010 6:43 pm Post subject: Re: Validating a date |
|
|
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.
| Quote: | <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: | <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..  _________________ speechles' eggdrop tcl archive |
|
| Back to top |
|
 |
arfer Master

Joined: 26 Nov 2004 Posts: 436 Location: Manchester, UK
|
Posted: Wed Jan 27, 2010 8:47 pm Post subject: |
|
|
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 |
|
| Back to top |
|
 |
|