Prev: tcl, tclreadline and expect issue
Next: Tk [photo]: when does a dithering process occur ?
From: Craig on 30 Jul 2010 16:00
On 7/30/2010 12:19 PM, Robert Heller wrote:
> The problem is that all three are not really meaningful*without* a
> specified time. That is 'today', 'yesterday', and 'tomorrow' are
> abiguous and there is no reason to expect consistent results when they
> are used without a time. 'It is not a bug, it is a feature.'

I think I disagree with this. This is the section of the clock/free form scan
man page that applies to this:

"First, any absolute date and/or time is processed and converted. Using that
time as the base, day-of-week specifications are added. Next, relative
specifications are used. If a date or day is specified, and no absolute or
relative time is given, midnight is used."

I see no requirement that a time be given and it explicitly says that if one is
not given then 'midnight is used'. I think, actually, that 'now' is a special
case, and that 'today' appears to be a synonym for 'now'.

Just because a feature is deprecated, doesn't mean it should be broken. On the
other hand, it might mean no one wants to fix it, which I can understand.

From: Craig on 30 Jul 2010 23:18
Here's why this happens (from clock.tcl):
in proc FreeScan

[...]if { [llength $parseWeekday] != 0
|| [llength $parseOrdinalMonth] != 0
|| ( [llength $parseRel] != 0
&& ( [lindex $parseRel 0] != 0
|| [lindex $parseRel 1] != 0 ) ) } {
dict set date secondOfDay 0
}

$parseRel = {0 0 0} for both 'now' and 'today', and this bit of code does not
distinguish between them. lindex $parseRel 1 is the problem in detail. fixing
this could be a bit ugly, but could be done by searching for the string "now"
(or "today") and adding it to the test. it's a hack, in a way, because most of
the ugly string parsing has been nicely encapsulated in the legacy parser.

I'd change the docs to reflect that the relative "now" modifier, w/o a time does
not default to midnight, too.

(btw, i have nothing but admiration for anyone who ever worked on clock
command(s). really. I'm going to go back and work through the Oldscan parser a
bit more carefully as a complete example for something else I've been thinking
about converting to a grammar.)

craig

On 7/28/2010 1:45 AM, yahalom wrote:
> I see no difference between "clock scan now" and "clock scan today"
> also today is inconsistent with other relative dates
>
> doing:
> %clock format [clock scan yesterday]
>
> %Mon Jul 19 00:00:00 IDT 2010
>
> %clock format [clock scan tomorrow]
>
> Wed Jul 21 00:00:00 IDT 2010
>
> %clock format [clock scan today]
>
> %Tue Jul 20 14:41:13 IDT 2010
>
> which is same as
>
> %clock format [clock scan now]
>
> I would expect:
> %clock format [clock scan today]
>
> %Tue Jul 20 00:00:00 IDT 2010
>
> is this a bug?
From: John Mercogliano on 1 Aug 2010 03:46
On Jul 30, 11:18 pm, Craig <ask...(a)somewhere.net> wrote:
> Here's why this happens (from clock.tcl):
> in proc FreeScan
>
> [...]if { [llength $parseWeekday] != 0
>                || [llength $parseOrdinalMonth] != 0
>                || ( [llength $parseRel] != 0
>                     && ( [lindex $parseRel 0] != 0
>                          || [lindex $parseRel 1] != 0 ) ) } {
>         dict set date secondOfDay 0
>   }
>
> $parseRel = {0 0 0} for both 'now' and 'today', and this bit of code does not
> distinguish between them. lindex $parseRel 1 is the problem in detail. fixing
> this could be a bit ugly, but could be done by searching for the string "now"
> (or "today") and adding it to the test. it's a hack, in a way, because most of
> the ugly string parsing has been nicely encapsulated in the legacy parser..
>
> I'd change the docs to reflect that the relative "now" modifier, w/o a time does
> not default to midnight, too.
>
> (btw, i have nothing but admiration for anyone who ever worked on clock
> command(s). really. I'm going to go back and work through the Oldscan parser a
> bit more carefully as a complete example for something else I've been thinking
> about converting to a grammar.)
>
> craig
>
> On 7/28/2010 1:45 AM, yahalom wrote:
>
>
>
> > I see no difference between "clock scan now" and "clock scan today"
> > also today is inconsistent with other relative dates
>
> > doing:
> > %clock format [clock scan yesterday]
>
> > %Mon Jul 19 00:00:00 IDT 2010
>
> > %clock format [clock scan tomorrow]
>
> > Wed Jul 21 00:00:00 IDT 2010
>
> > %clock format [clock scan today]
>
> > %Tue Jul 20 14:41:13 IDT 2010
>
> > which is same as
>
> > %clock format [clock scan now]
>
> > I would expect:
> > %clock format [clock scan today]
>
> > %Tue Jul 20 00:00:00 IDT 2010
>
> > is this a bug?- Hide quoted text -
>
> - Show quoted text -

I don't know if anyone has looked but at least in 8.4.12 on hp-ux all
those commands work as expected returning the full date/time. But on
8.5.2 on my activestate windows version I experience the problem
described.
From: yahalom on 1 Aug 2010 11:25
On Aug 1, 12:46 pm, John Mercogliano <jxmer...(a)sentara.com> wrote:
> On Jul 30, 11:18 pm, Craig <ask...(a)somewhere.net> wrote:
>
>
>
> > Here's why this happens (from clock.tcl):
> > in proc FreeScan
>
> > [...]if { [llength $parseWeekday] != 0
> >                || [llength $parseOrdinalMonth] != 0
> >                || ( [llength $parseRel] != 0
> >                     && ( [lindex $parseRel 0] != 0
> >                          || [lindex $parseRel 1] != 0 ) ) } {
> >         dict set date secondOfDay 0
> >   }
>
> > $parseRel = {0 0 0} for both 'now' and 'today', and this bit of code does not
> > distinguish between them. lindex $parseRel 1 is the problem in detail. fixing
> > this could be a bit ugly, but could be done by searching for the string "now"
> > (or "today") and adding it to the test. it's a hack, in a way, because most of
> > the ugly string parsing has been nicely encapsulated in the legacy parser.
>
> > I'd change the docs to reflect that the relative "now" modifier, w/o a time does
> > not default to midnight, too.
>
> > (btw, i have nothing but admiration for anyone who ever worked on clock
> > command(s). really. I'm going to go back and work through the Oldscan parser a
> > bit more carefully as a complete example for something else I've been thinking
> > about converting to a grammar.)
>
> > craig
>
> > On 7/28/2010 1:45 AM, yahalom wrote:
>
> > > I see no difference between "clock scan now" and "clock scan today"
> > > also today is inconsistent with other relative dates
>
> > > doing:
> > > %clock format [clock scan yesterday]
>
> > > %Mon Jul 19 00:00:00 IDT 2010
>
> > > %clock format [clock scan tomorrow]
>
> > > Wed Jul 21 00:00:00 IDT 2010
>
> > > %clock format [clock scan today]
>
> > > %Tue Jul 20 14:41:13 IDT 2010
>
> > > which is same as
>
> > > %clock format [clock scan now]
>
> > > I would expect:
> > > %clock format [clock scan today]
>
> > > %Tue Jul 20 00:00:00 IDT 2010
>
> > > is this a bug?- Hide quoted text -
>
> > - Show quoted text -
>
> I don't know if anyone has looked but at least in 8.4.12 on hp-ux all
> those commands work as expected returning the full date/time. But on
> 8.5.2 on my activestate windows version I experience the problem
> described.

true
I checked also on linux 8.4.16
clock format [clock scan today]
Sun Aug 01 20:50:34 IST 2010
% clock format [clock scan yesterday]
Sat Jul 31 20:50:51 IST 2010
% info tclversion
8.4

so it is a bug but not in the direction I wanted it :-). But this also
makes it clear that sadly, this is not something you can rely on.
From: Glenn Jackman on 9 Aug 2010 10:41
At 2010-07-28 04:45AM, "yahalom" wrote:
> I see no difference between "clock scan now" and "clock scan today"
> also today is inconsistent with other relative dates
>
> doing:
> %clock format [clock scan yesterday]
>
> %Mon Jul 19 00:00:00 IDT 2010
>
> %clock format [clock scan tomorrow]
>
> Wed Jul 21 00:00:00 IDT 2010
>
> %clock format [clock scan today]
>
> %Tue Jul 20 14:41:13 IDT 2010


Jumping late into the party, the proper way to do date calculations is
with [clock add]:

set now [clock seconds]
set yesterday [clock add $now -1 day]
set tomorrow [clock add $now 1 day]

--
Glenn Jackman
Write a wise saying and your name will live forever. -- Anonymous
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: tcl, tclreadline and expect issue
Next: Tk [photo]: when does a dithering process occur ?