clock command in tcl8.4 problem !

Hello,

Tcllib1.7 has a problem with tclsh8.4 :

using the mime/smtp module, I've got the message :

unable to convert date-time string "13 avr 2005 12:50:53"


See the problem ? reading the code I discover that :

The string returned by

set value [clock format $clock -format "%d %b %Y %H:%M:%S"]

is in french ("avr" instead of "apr") ! (I'm a french guy and my Suse9.0
is setup in french !)

But the string expected by [clock scan $value] must be in english !

When I was using tcllib1.7 with tclsh8.3, everything was fine.
When I compile the code with tcl/tk 8.3 via protcl1.4.1, everything is fine.

So my question is :
How can I tell [clock format] to return english date ?
or
How can I tell [clock scan] to accept french date ?
or
Does somebody fix this bug in Tcllib1.7 ?

Thanks for any help,
Vincent.

Vincent Texier wrote:
> Hello,
>
> Tcllib1.7 has a problem with tclsh8.4 :
>
> using the mime/smtp module, I've got the message :
>
> 	unable to convert date-time string "13 avr 2005 12:50:53"
>
>
> See the problem ? reading the code I discover that :
>
> The string returned by
>
> 	set value [clock format $clock -format "%d %b %Y %H:%M:%S"]
>
> is in french ("avr" instead of "apr") ! (I'm a french guy and my
Suse9.0
> is setup in french !)
>
> But the string expected by [clock scan $value] must be in english !
>
> When I was using tcllib1.7 with tclsh8.3, everything was fine.
> When I compile the code with tcl/tk 8.3 via protcl1.4.1, everything
is fine.
>
> So my question is :
> How can I tell [clock format] to return english date ?
> or
> How can I tell [clock scan] to accept french date ?
> or
> Does somebody fix this bug in Tcllib1.7 ?
>
> Thanks for any help,
> Vincent.


Alternatively, as a workaround, you might *translate* the returned
date. Here is an example proc:

proc fr2en {date} {
regsub "fev" $date "Feb" date
regsub "avr" $date "Apr" date
regsub "mai" $date "May" date
regsub "jui" $date "Jul" date
regsub "aou" $date "Aug" date
return $date
}

set value [fr2en [clock format $clock -format "%d %b %Y %H:%M:%S"]]

Rgrds,
Khaled

At 2005-04-21 08:01AM, Khaled <ksubs@free.fr> wrote:
>  proc fr2en {date} {
>     regsub "fev" $date "Feb" date
>     regsub "avr" $date "Apr" date
>     regsub "mai" $date "May" date
>     regsub "jui" $date "Jul" date
>     regsub "aou" $date "Aug" date
>     return $date
>  }

If you're going to do that, use [string map]
proc fr2en {date} {
return [string map {fev Feb avr Apr mai May jui Jul aou Aug} $date]
}

--
Glenn Jackman
NCF Symin
glennj@ncf.ca

Vincent Texier wrote:
> Hello,
>
> Tcllib1.7 has a problem with tclsh8.4 :
>
> using the mime/smtp module, I've got the message :
>
>     unable to convert date-time string "13 avr 2005 12:50:53"
>
>
> See the problem ? reading the code I discover that :
>
> The string returned by
>
>     set value [clock format $clock -format "%d %b %Y %H:%M:%S"]
>
> is in french ("avr" instead of "apr") ! (I'm a french guy and my Suse9.0
> is setup in french !)
>
> But the string expected by [clock scan $value] must be in english !
>
> When I was using tcllib1.7 with tclsh8.3, everything was fine.
> When I compile the code with tcl/tk 8.3 via protcl1.4.1, everything is
> fine.
>
> So my question is :
> How can I tell [clock format] to return english date ?
> or
> How can I tell [clock scan] to accept french date ?
> or
> Does somebody fix this bug in Tcllib1.7 ?
>
> Thanks for any help,
> Vincent.

Is there a case here for having a -rfc822 option for clock or perhaps a
command like

smtp::date

This would provide users with a simple way of avoiding this problem and
I think is probably sufficiently common to warrant one of the above.
FWIW I use

proc rfc822Date {} {
return [clock format [clock seconds] -format {%a, %e %b %Y %T %Z}
-gmt 1]
}

There is some variation allowed with TZ otherwise the requirement seems
well defined.

Simon Geard


Standard for ARPA Internet Text Messages

5.  DATE AND TIME SPECIFICATION

5.1.  SYNTAX

date-time   =  [ day "," ] date time        ; dd mm yy
;  hh:mm:ss zzz

day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
/  "Fri"  / "Sat" /  "Sun"

date        =  1*2DIGIT month 2DIGIT        ; day month year
;  e.g. 20 Jun 82

month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
/  "May"  /  "Jun" /  "Jul"  /  "Aug"
/  "Sep"  /  "Oct" /  "Nov"  /  "Dec"

time        =  hour zone                    ; ANSI and Military

hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59

zone        =  "UT"  / "GMT"                ; Universal Time
; North American : UT
/  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
/  "CST" / "CDT"                ;  Central:  - 6/ - 5
/  "MST" / "MDT"                ;  Mountain: - 7/ - 6
/  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
/  1ALPHA                       ; Military: Z = UT;
;  A:-1; (J not used)
;  M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT )        ; Local differential
;  hours+min. (HHMM)

Vincent Texier wrote:
> So my question is :
> How can I tell [clock format] to return english date ?
> or
> How can I tell [clock scan] to accept french date ?
> or
> Does somebody fix this bug in Tcllib1.7 ?

The short answer: "Fixed in Tcl 8.5".  In Tcl 8.5, the [clock]
command does not use the system locale as default, because of
precisely this problem. (The [clock] command in 8.5, though, does
accept an optional '-locale' argument that lets you specify
the desired locale, so you don't lose localisation.)

There are a couple of things that you could try in 8.4.  One is
to save and restore the LC_TIME environment variable around the
call to [clock format]:

set savedLC_TIME $env(LC_TIME)
set env(LC_TIME) C
# ... code that works with [clock]
set env(LC_TIME) savedLC_TIME

Another approach would be to modify the smtp module to use [clock]
only to generate numeric strings, and then have a separate lookup
table convert month and wday numbers to names.

A third approach, as others have mentioned, is to repair the
strings after the fact with [string map].

Sorry that I don't have better news for you.  I'm afraid that the
8.5 [clock] command can't be ported back onto the 8.4 branch (it
introduces enough subtle incompatibilities that a backport is
unwise). And the bad behaviour in 8.4 can be fixed only at the cost
of breaking localisation entirely.


--
73 de ke9tv/2, Kevin