Tcl - clock scan oddity

Author

clock scan oddity

Donald Arseneau

2005-06-06, 4:00 pm

Good Monday morning,
Here is a puzzle I just ran into.

clock scan "x15:19:01 Jun 11, 2000" -gmt 1

returns 960697141, though I expected an error. Does anyone
know what is the "x" is interpretd as?

"15:19:01 Jun 11, 2000" (gmt) is 960736741, which is 11 hours
different.

--
Donald Arseneau asnd@triumf.ca

Khaled

2005-06-06, 8:58 pm

Donald Arseneau wrote:
> Good Monday morning,
> Here is a puzzle I just ran into.
>
> clock scan "x15:19:01 Jun 11, 2000" -gmt 1
>
> returns 960697141, though I expected an error. Does anyone
> know what is the "x" is interpretd as?
>
> "15:19:01 Jun 11, 2000" (gmt) is 960736741, which is 11 hours
> different.
>
> --
> Donald Arseneau asnd@triumf.ca

Hello at a late hour on Monday,
in Europe ;-)

It seems that "x" is not the only interpreted character. I did a small
test using the following piece of code:

foreach x [list a b c d e f g h i j k l m n o p q r s t u v w x y z] {
set inst 0
foreach y [list $x [string toupper $x]] {
puts -nonewline [format %-3s $y]
if {[catch {puts -nonewline [format %-11s [set inst \
[clock scan "${y}15:19:01 Jun 11, 2000" -gmt 1]]]}]} {
puts -nonewline [format %-11s ""]
}
}
if {$inst != 0} {
puts [clock format [expr $ref - $inst] -format %H:%M:%S]
} else {puts ""}
}

The code evaluates [clock scan "${y}15:19:01 Jun 11, 2000" -gmt 1],
with ${y} replaced each time by an alphabetic character in lower and
upper cases. It shows [clock scan] value for each character and the
difference in hour:min:sec between the original date-time string and
the same string with the character inserted.

Here is the result:

a 960740341 A 960740341 23:00:00
b 960743941 B 960743941 22:00:00
c 960747541 C 960747541 21:00:00
d 960751141 D 960751141 20:00:00
e 960754741 E 960754741 19:00:00
f 960758341 F 960758341 18:00:00
g 960761941 G 960761941 17:00:00
h 960765541 H 960765541 16:00:00
i 960769141 I 960769141 15:00:00
j J
k 960772741 K 960772741 14:00:00
l 960776341 L 960776341 13:00:00
m 960779941 M 960779941 12:00:00
n 960733141 N 960733141 01:00:00
o 960729541 O 960729541 02:00:00
p 960725941 P 960725941 03:00:00
q 960722341 Q 960722341 04:00:00
r 960718741 R 960718741 05:00:00
s S
t 960711541 T 960711541 07:00:00
u 960707941 U 960707941 08:00:00
v 960704341 V 960704341 09:00:00
w 960700741 W 960700741 10:00:00
x 960697141 X 960697141 11:00:00
y 960693541 Y 960693541 12:00:00
z 960736741 Z 960736741 00:00:00

It is shown that:
- interpretation is the same for the same letter in lower
and upper cases.
- with j/J and s/S inserted, [clock scan] was not able to
interpret the date-time string.
- both y/Y and m/M give a difference of 12 hours from the
original string.
- no letter gives 6 hours differnce.
- a/A gives the maximum 23 hours differnce, and z/Z gives
no differnce.
- it seems that there is some sort of ordering of the diffe-
rences given by the interpretation of different letters.
- all letters give perfect hours differences, no minutes or
seconds.

Further testing showed that:
- The following strings are interpreted similarly:
"${y}15:19:01 Jun 11, 2000"
"15:19:01${y} Jun 11, 2000"
"15:19:01 Jun 11, 2000${y}"
They give exactly the same results shown above.

- if "${y}" is put anywhere else in the string, interpretation
fails for all letters.

I don't know the reason for this, but I tried to find some
mathematical/logical patterns in these results, oh but I'm tired. It
would be easier perhaps to have a look at the C code for [clock]. I
might be doing this tomorrow if I'm not still tired :^)

Khaled

Khaled

2005-06-06, 8:58 pm

Khaled wrote:
>
> Hello at a late hour on Monday,
> in Europe ;-)
>

Sorry forgot something,
seems that I'm really tired ;^)

set ref [clock scan "15:19:01 Jun 11, 2000" -gmt 1]

Khaled

Donald Arseneau

2005-06-07, 9:00 am

"Khaled" <nospam.ksubs@free.fr> writes:

> Donald Arseneau wrote:
[color=darkred]
> It seems that "x" is not the only interpreted character.

I did some reading and I see that there are single-letter
military (presumably USA/NATO) designations of time zones; and
"X" is bering time, UTC -11.

Presumably that would be spoken as "X-ray" time. Likewise,
I knew about "Zulu" == UTC, but thought it stood for "zero";
however UTC == WET == "Z" == "Zulu". (UTC+1 == CET == "a" ==
"Alpha").

All letters are used except J and Y (but Y would logically
equal M, and Tcl interprets it so.)

Non-hour zones get an asterisk; Newfoundland time is P*.
However [clock scan "P*15:19:01 Jun 11, 2000"] returns
error. (I don't know whether the military jargon calls that
"Papa asterisk" or "Papa star" or whatever.)

I don't understand what is the effect of the "-gmt 1" when
parsing such a time.

> - with j/J and s/S [-> error]

That is odd! The J is in agreement, but S is UTC -6 ==
central time in North America.

> - both y/Y and m/M give a difference of 12 hours from the
> original string.

The wikipedia lists no Y, but it would equal M.

> - no letter gives 6 hours differnce.

They are supposed to be F (+6) and S (-6)

The missing S looks like a bug.

--
Donald Arseneau asnd@triumf.ca

Kevin Kenny

2005-06-07, 8:58 pm

Donald Arseneau wrote:
> I did some reading and I see that there are single-letter
> military (presumably USA/NATO) designations of time zones; and
> "X" is bering time, UTC -11.
>
> Presumably that would be spoken as "X-ray" time. Likewise,
> I knew about "Zulu" == UTC, but thought it stood for "zero";
> however UTC == WET == "Z" == "Zulu". (UTC+1 == CET == "a" ==
> "Alpha").
>
> All letters are used except J and Y (but Y would logically
> equal M, and Tcl interprets it so.)

Not so! M is 12 hours east of Greenwich. Y is twelve hours
west. Same time, different dates.

> I don't understand what is the effect of the "-gmt 1" when
> parsing such a time.

No effect; if there's a timezone in the string, it overrides any
timezone specified on the command line.

> That is odd! The J is in agreement, but S is UTC -6 ==
> central time in North America.

S is not accepted by the free-form date/time parser because
it's ambiguous. "2000 s" could mean "twenty hours, zero minutes,
time zone Sierra," or "two thousand seconds from the reference
time point." The parser always uses "s" for seconds, never
for a timezone.

This is basically unfixable in the free-form parser. If you
know what format you're expecting, you can get what you want
in the 8.5 fixed-form parser:

% clock scan "18:00 S" -format "%H:%M %Z"
1118188800

In 8.5, I recommend never using the free-form parser, but
instead always giving a -format argument to [clock scan].
If that is too restrictive, consider a recognizer for a
family of formats that you intend to accept. For instance,
http://wiki.tcl.tk/13094 has code to recognize date/time
strings that conform to ISO8601. (I've also got an RFC2822
version of the thing lying about, if you need one.)

--
73 de ke9tv/2, Kevi

Donald Arseneau

2005-06-08, 8:59 am

Kevin Kenny <kennykb@acm.org> writes:

> Donald Arseneau wrote:
>
> Not so! M is 12 hours east of Greenwich. Y is twelve hours
> west. Same time, different dates.

Yes, same zone, but not same time.

> S is not accepted by the free-form date/time parser because
> it's ambiguous.

Thanks, OK. I wonder if it would be interpreted as a time zone
when it occurs at the beginning? Not that I need it for anything.

> http://wiki.tcl.tk/13094 has code to recognize date/time
> strings that conform to ISO8601.

This could be useful, because I was accepting (and converting) user
input.

--
Donald Arseneau asnd@triumf.ca

Sponsored Links