wnicholls Posted November 1, 2017 Report Share Posted November 1, 2017 Sorry I don't have time to investigate this, but my tool which I swear worked last month has broke this month. Take this command: cm find changeset where date ">=" '2017/10/01' --xml Actual output today (build 6.0.16.1723): ... <CHANGESET> <ID>5346</ID> <CHANGESETID>268</CHANGESETID> <COMMENT>yada yada yada</COMMENT> <DATE>11/10/2017 5:20:08 PM</DATE> <OWNER>walter</OWNER> ... Expected: ISO-standard dates, ie ... <DATE>2017/10/11T17:20:08</DATE> ... I'm sure the previous version I had installed produced something like this. I'm pushing this through an XSLT transform to the get the output I want. XLST 1.0 (stuck with it) has problems with dates anyway, Needless to say, a localised time format like this with AM/PM issues is a nightmare. Sorry for terseness, I'm serious about not having time to investigate this - seems pretty obvious though. Not what I need to be doing - aaargh!!!!!!! <s> Link to comment Share on other sites More sharing options...
psantosl Posted November 2, 2017 Report Share Posted November 2, 2017 We'll look into it. Link to comment Share on other sites More sharing options...
manu Posted November 2, 2017 Report Share Posted November 2, 2017 Hello @wnicholls, I'm not aware of changes at the default date format, I'm wondering if the os has something to do here. Anyway, in order to avoid this kind of issues I recommend to use a custom date filter, you can do it like this: cm find changeset "where date >= '2017/10/01 00:00'" --dateformat="yyyy/MM/dd HH:mm" --xml Hope it helps! Link to comment Share on other sites More sharing options...
wnicholls Posted November 8, 2017 Author Report Share Posted November 8, 2017 It's possible that a .NET framework patch could have affected this. Hard for me to check unless I can find one of the old temp files my reporting tool used. I may have just got mixed up XSLT too. Because your tools are inconsistent: cm find changeset produces all XML element names in <UPPERCASE> and the aforementioned formatted date/time strings. cm hist on the other hand produces ProperCase element names and ISO times eg <CreationDate>2015-09-20T17:59:04.0000000+12:00</CreationDate> My little reporting tool started out with cm hist and tried cm find changeset only last month (mostly, because there is no way to put a date filter on cm hist query; but also because it was changesets I actually wanted to report on) It would now break existing consumers of the XML (exactly like mine) but I think exporting dates in XML as ISO-8601 compliant strings is definitely best practice and so is consistency. HOWEVER, good luck agreeing what is best practice with timezones. Link to comment Share on other sites More sharing options...
wnicholls Posted November 8, 2017 Author Report Share Posted November 8, 2017 Incidentally I found that using --dateformat it was very fussy about the input format. Even/especially --dateformat="s" which ought be exactly what I want: > cm find changeset where "date > '2017-10-01'" --dateformat="s" --xml The value '2017-10-01' is not valid for field 'date' on query "find changeset where date > '2017-10-01'". The field 'date' type is 'date'. > cm find changeset where "date > '2017-10-01T00:00:00'" --dateformat="s" --xml <?xml version="1.0" encoding="utf-8" ?> <PLASTICQUERY> ... etc etc - ie ok ... Without the dateformat specifier, I never thought twice about it, and it seems to accept everything from 2017-10-01 1/10/2017 and even '1 Oct' (although '1st Oct' foiled it) So I've swapped one pain for another - fussy user INPUT! Same behaviour Linux and Windows. Although with Linux the default output format was, as expected different eg <DATE>25/10/2017 4:47:55 p.m.</DATE> Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.