Tcl Source Code

View Ticket
Ticket UUID: e7a722cd3573fedda5d1e528f95902776f996e06
Title: confusing precedence of some clock-formats by `clock scan -format`
Type: Bug Version: all
Submitter: sebres Created on: 2016-12-19 15:21:31
Subsystem: 16. Commands A-H Assigned To: kbk
Priority: 5 Medium Severity: Important
Status: Closed Last Modified: 2017-05-30 09:25:16
Resolution: Fixed Closed By: sebres
    Closed on: 2017-05-30 09:25:16
IMHO the calculating of precedence and therefore several test cases (e.g. clock-11.x with very confusing and absurdly logic) are wrong.


	# from clock-11.1:
	puts [set d [clock scan {1970-01-01 002} -format "%Y-%m-%d %j" -gmt 1]]\t[clock format $d -format "%Y-%m-%d  %j"]
	# from clock-11.4:
	puts [set d [clock scan {002 1970-01-01} -format "%j %Y-%m-%d" -gmt 1]]\t[clock format $d -format "%Y-%m-%d  %j"]

	# returns accordingly:
	86400	1970-01-02  002
	0	1970-01-01  001

But according to `DateParseActions` both "%Y%m%d" and "%Y%j" have the same priority! (but "%Y%m%d" takes place always before "%Y%j"):
	{ century yearOfCentury month dayOfMonth } 3 { ... }
	{ century yearOfCentury dayOfYear } 3 { ... }
	{ yearOfCentury month dayOfMonth } 4 { ... }
	{ yearOfCentury dayOfYear } 4 { ... }


That is IMHO definitive a bug within `MakeParseCodeFromFields` - because if both formats have the same priority, it should return the same result (likely "%Y%m%d" should wins in both cases). At least this logic used in ALL other test cases (e. g. in simplified terms if "month" available "mmdd" over "ddd", otherwise "ddd" over "dd").

It's worse still more that in first case wins prio.3 with "%Y%j" (so second rule!), in second case - prio.4 with "%Y%m%d" (so totally ignores both prio.3 rules)...

I think, as result of this confusing bug, several test cases have been artificially made "correctly".

P.S. Request for the fast feedback, because I'm working on newer tcl-clock engine and this is important for me, because my decision rules here are logic-based (not priority-based).
User Comments: sebres added on 2017-05-30 09:25:16:
Fixed now for 8.6 / trunk (within merge to new clock-engine, see *-clock-speedup branches).
If someone need the fix for 8.5, please contact me.

sebres added on 2017-01-03 20:28:26:
In the meantime I'm assuming that this would be a "bug" and in my new clock engine I've made the logical precedence, where "%Y%m%d" always wins before "%Y%j".

It is not 100% backwards compatible, but IMHO solely correct solution (and questionable whether such artifical formats used in the practice).

See "clock.test" changes in

Affected cases are: clock-11.1 to clock-11.3; clock-11.9 to clock-11.11; clock-11.14 and clock-11.15. 
Other clock-11.* using already same precedence ("mmdd" over "ddd").