[clock format now ...] and [clock add now ...]
Ronnie Brunner
The following patch to clock.tcl (against CVS head) would allow to use
"now" instead of [clock seconds] (or any other integer) wherever the
clock command takes a timeVal as argument (only in [clock format] and
[clock add] afaik).
The solution is just as fast as the current code and introduces no
shimmering (because the check for now is only done when an error would
be thrown anyway).
I'm aware that it is by now means faster than just using [clock seconds]
in the script, but I'm also pretty sure that the resulting code is more
readable. So I see only advantages..
Kenny? (I guess this post is more or less addressed to you :-)
Thx for checking
Ronnie
> cvs diff -u clock.tcl
Index: clock.tcl
===================================================================
RCS file: /cvsroot/tcl/tcl/library/clock.tcl,v
retrieving revision 1.29
diff -u -r1.29 clock.tcl
--- clock.tcl 27 Dec 2005 17:39:02 -0000 1.29
+++ clock.tcl 7 Jan 2006 14:43:25 -0000
@@ -708,8 +708,12 @@
"cannot use -gmt and -timezone in same call"
}
if { ![string is wide -strict $clockval] } {
- return -code error \
- "expected integer but got \"$clockval\""
+ if { [string eq now $clockval] } {
+ set clockval [clock seconds]
+ } else {
+ return -code error \
+ "expected integer but got \"$clockval\""
+ }
}
if { ![string is boolean -strict $gmt] } {
return -code error \
@@ -4301,7 +4305,11 @@
?-gmt boolean? ?-locale LOCALE? ?-timezone ZONE?\""
}
if { [catch { expr wide($clockval) } result] } {
- return -code error $result
+ if { [string eq now $clockval] } {
+ set clockval [clock seconds]
+ } else {
+ return -code error $result
+ }
}
set offsets {}
Gerald W. Lester
> I know I tried before, but the thread somehow died ...
>
> The following patch to clock.tcl (against CVS head) would allow to use
> "now" instead of [clock seconds] (or any other integer) wherever the
> clock command takes a timeVal as argument (only in [clock format] and
This should be submitted as a TIP (see http://www.tcl.tk/cgi-bin/tct/tip/)
or at least an enhancement require (see
http://sourceforge.net/tracker/?atid=110894&group_id=10894&func=browse).
Please submit the request via one (or both) of these channels.
Ronnie Brunner
> This should be submitted as a TIP (see
> http://www.tcl.tk/cgi-bin/tct/tip/) or at least an enhancement require
> (see
> http://sourceforge.net/tracker/?atid=110894&group_id=10894&func=browse).
>
> Please submit the request via one (or both) of these channels.
I submitted it to the tracker on sf. But I didn't really want to submit
a bug (cause it isn't) and it felt less presumptuous just to post it on
c.l.t. OK, a TIP would have been more appropriate, but the process
seemed more complicated. Sorry. Next time I'll submit a TIP ;-)
Ronnie
Kevin Kenny
> I know I tried before, but the thread somehow died ...
>
> The following patch to clock.tcl (against CVS head) would allow to use
> "now" instead of [clock seconds] (or any other integer) wherever the
> clock command takes a timeVal as argument (only in [clock format] and
> [clock add] afaik).
> Kenny? (I guess this post is more or less addressed to you :-)
Just hadn't got around to it yet. I also want to TIP a couple of
other little changes: [clock add $time 1 Wednesday] (an oversight:
otherwise there's no equivalent to [clock scan "next Wednesday"]
without resorting to free-form scan), and some clarifications to
free-form parsing that may actually make it supportable. The
latter involves a nearly complete rewrite of the free-form parser
because YACC is quite the wrong tool for the job; the grammar
is not LALR(1) and can't readily be massaged into LALR(1) form.
I was planning to write the TIP and call the vote on all the
changes together so as to avoid extra voting - I don't expect
any of the tweaks to be controversial.
--
73 de ke9tv/2, Kevin
Ronnie Brunner
Sorry. Just realized that your first name is Kevin, not Kenny.
> Just hadn't got around to it yet. I also want to TIP a couple of
> other little changes: [clock add $time 1 Wednesday] (an oversight:
> otherwise there's no equivalent to [clock scan "next Wednesday"]
> without resorting to free-form scan), and some clarifications to
> free-form parsing that may actually make it supportable.
Makes sense. In the post I referred to, I wrote about an
inconsistency of clock scan:
% clock format [clock scan "tomorrow"]
Tue Aug 30 00:00:00 +0200 2005
% clock format [clock scan "today"]
Mon Aug 29 19:51:15 +0200 2005
% clock format [clock scan "yesterday"]
Sun Aug 28 00:00:00 +0200 2005
-> "today" is not consistent with "yesterday" and "tomorrow"
% clock format [clock scan "now - 1 days"]
Sun Aug 28 00:00:00 +0200 2005
% clock format [clock scan "now + 0 days"]
Mon Aug 29 19:52:33 +0200 2005
% clock format [clock scan "now + 1 days"]
Tue Aug 30 00:00:00 +0200 2005
-> "now + 0 days" is not consistent with "now +/- 1 days"
There is actually more to it: even if scanning "now + 0 days" has to
return the current time by design (which I doubt), then
% clock format [clock scan "now + 0 hours"]
Mon Jan 09 16:40:39 +0100 2006
% clock format [clock scan "now + 1 hour"]
Mon Jan 09 17:40:47 +0100 2006
%
This is still inconsistent, as the second scan ("now + 1 hour") should
have returned "Mon Jan 09 17:00:00 +0100 2006" if it was consistent
with adding days.
That's actually my reasoning for suspecting that "now + 1 day" should
actually be parsed to the same as "now + 24 hours". (Same goes for
"now + 1 year" etc.)
All in all I'd say either all "time + some unit" return a result
rounded to "unit" (as "now + 1 day" rounds to day) or it is always
"time + some * (unit in seconds)" (as in hour, minute and
seconds). The second approach would be the most consistent, as it also
solves the problem of "now + 0 days", which then will be (exactly)
"now". Additionally and even better: it's consistent with [clock add].
Sorry to be so verbose ;-) Hope it's at least clear what I mean.
Regards
Ronnie
--
Ronnie Brunner | ronnie....@netcetera.ch
phone +41 (0)44 247 79 79 | fax +41 (0)44 247 70 75
Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.ch
Donal K. Fellows
> That's actually my reasoning for suspecting that "now + 1 day" should
> actually be parsed to the same as "now + 24 hours". (Same goes for
> "now + 1 year" etc.)
What about when the clocks change? Or when there's a leap year?
Donal.
Ronnie Brunner
Naturally this has to be considered. My point did not concern these
cases, it merely states that imho, days / hours should not be truncated
in any case.
Your question is more like: when daylight changes, is "now + 1 day" in
23/25 or in 24 hours. I implicitly wrote it's 24 hours (which will then
shift the time). But to me this could also be the other way round.
The only thing I hope for is consistency: make all calculations as
consistent as possible. (E.g. if "now + 1 day" would change the hour in
case of DST (because it's an actual 24 hours being added), then it is
important that the same applies for "now + 1 year" in a leap year:
exactly 365 days should be added. Or, as I said: the other way round.)
Ronnie
Ronnie Brunner
> consistent as possible. (E.g. if "now + 1 day" would change the hour in
> case of DST (because it's an actual 24 hours being added), then it is
> important that the same applies for "now + 1 year" in a leap year:
> exactly 365 days should be added. Or, as I said: the other way round.)
btw: the other way round is probably more intuitive: add 23/25 hours
when DST changes and add 366 days in a leap year when calculating "now +
1 day" or "now + 1 year", because in most cases that would be what the
user wants (I guess).
Ronnie
Donal K. Fellows
> Naturally this has to be considered. My point did not concern these
> cases, it merely states that imho, days / hours should not be truncated
> in any case.
My point was that time arithmetic is full of these sorts of problems.
I'm so glad it was Kevin who cleaned this swamp out and not me. :-)
Donal.