[ tcl-Bugs-2010909 ] clock scan fails with %V

[SourceForge.net]

Bugs item #2010909, was opened at 2008-07-04 21:54
Message generated for change (Comment added) made by ferrieux
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2010909&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 03. Timer Events
Group: current: 8.5.3
Status: Pending
Resolution: Invalid
Priority: 5
Private: No
Submitted By: haertel, ruediger (haertel)
Assigned to: Kevin B KENNY (kennykb)
Summary: clock scan fails with %V

Initial Comment:
The clock scan command returns always the current week when the given format only contains the week (%V).

test-case showing failure

for {set week 0} {$week < 22} {incr week} {
     set x [clock scan "$week 2008" -format "%V %Y"]
     puts [clock format $x]
}

However it works correctly when a week day is supplied.

test-case workaround

 for {set week 0} {$week < 22} {incr week} {
     set x [clock scan "$week Sun" -format "%V %A"]
     puts [clock format $x]
 
}


This could be a fix in the code. In that it assumes the current day.

Or this could be a fix in the documentation. In that it is clearly stated that for the scan and format %V the week day shall be supplied to.


>From my point of view I'd prefer a fix in the code. Primarily because clock already assumes in the workaround that the year is the current year.

----------------------------------------------------------------------

>Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-07-05 17:53

Message:
Logged In: YES
user_id=496139
Originator: NO

Hmm, you seem to be concentrating on under-specification of the input
string, while I think it is useful to define it for the format string
instead (the only circumstance under which "2008 04" should be reasoned
about ex nihilo, is free-form-scanning. We are not in this case, we do have
a format string.).

Then, we can define the "compatibility principle" in a very simple
fashion:

  [clock format [clock scan $s -format $f] -format $f]
  is always "nearly equal" to $s (except for whitespace
  and other irrelevant chars)

This means that for "underspecified formats" like "%Y %V", [clock scan] is
free to *choose* (as in "not specified") among several values, provided the
above equation holds. This choice can be driven by simplicity of
implementation, or by some objective function to optimize (like "closest to
now").

Kevin, don't you think this compatibility principle would be a good guide
?
If we admit it, then clearly the current behavior with %V is a bug...
(But please also notice that enforcing it would not require a TIP, since I
can't imagine a purposeful use of "%Y %V" returning a date in the wrong
week for example).

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2008-07-05 01:50

Message:
Logged In: YES
user_id=99768
Originator: NO

You're right, but...

if underspecified ones are allowed from both ends, then an anomaly
results with:

2008-5 in place of 2008-W27-5

or

2008-04  in place of 2008-07-04

Is that "a completely specified 2008 (meaning the start of the year)
together with a redundant day of week or month"?
A completely specified "'day 4 of the current month' with
a redundant year" or "'day 5 of the current week' with a
redundant year"?
"A specification that means day 4 of the month in 2008 corresponding
with the base month" or "day 5 of the week in 2008 corresponding
with the base week"?
An error?
Something else?

Rather than worry about what the combination of under- and
over-specified dates means, I punted, and said "there must
be enough information in the specification to identify
a unique day"

I'm willing to revisit it, if someone wants to spec it out
in a TIP.

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-07-05 01:36

Message:
Logged In: YES
user_id=496139
Originator: NO

Sorry, but I don't understand the reference to redundant groups: here we
are on the other end of the spectrum -- underspecified rather than
redundant. When we parse "2008 23" with "%Y %H" we get a similar situation,
but the result is compatible with all specified data, it is a date whose
time-of-day is 23:00 in year 2008. The same with %V violates the
compatibility rule since it gives noon today, and today is not in week 01.

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2008-07-05 00:02

Message:
Logged In: YES
user_id=99768
Originator: NO

A careful reading of clock.n (under SCANNING TIMES) shows that
[clock] here works as designed and documented.  I concede that
the behaviour of ignoring the 'week' format group in that case
is puzzling, but it fits with the fact that redundant groups
are (and must be) ignored in other cases - for instance,
in parsing an RFC2822 date, the day-of-the-week is presented
even though the other fields are sufficient to specify the date.

It is easy to parse a date like 2008-W27 if you need the
start of the week:

set date {2008-W27}
set secs [clock scan "$date-1" -format "%G-%V-%u"]

Another reason for the code to work the way it does is that
otherwise there is also a possibility of nonsense combinations
like "%G-%u" without a week number - either choosing a given
weekday in the first week, or a given weekday in the current
week number, would be surprising.



----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2010909&group_id=10894

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Tcl-Bugs mailing list
Tcl-Bugs@...
https://lists.sourceforge.net/lists/listinfo/tcl-bugs