When a buglist is requested in CSV format, it is presumably for further machine-based processing. Rather than listing dates such as .... 9:15:54 7/29/2002 10/16/2002 3:42:29 Sat 08:39 8/5/2002 It should use a consistent format recognizable as a date... probably... yyyy-mm-dd hh:mm:ss which seems to be a good way to dodge the d/m/y versus m/d/y i10n issue. [note - I DID mark this trivial]
One way to do this is for the templates to take over the job of formatting dates, which is now done in the CGI. This would probably be a good thing for l10n reasons. Another way would be to ditch the "feature" of different date formats for recent dates. It annoys me - I don't know about anyone else. We could use the standard date format of YYYY-MM-DD HH:MM:SS (as suggested by the reporter) throughout. Gerv
myk, dave: would removing the different time formats completely be acceptable, or not? Gerv
I prefer the "letting the templates do the formatting" approach, personally. Pass all the times in as unix timestamps :-) Provide a few filters (one with the date-sensitive formatting) for various default formats.
Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.
My CSV output (see attachment) has the date in both the Changed_Date and Open_Date columns for some records and just the Time in those columns for other records. Is this due to the same problems you described in earlier comments or is it a separate bug? Rich
This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to email@example.com or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.
Created attachment 176389 [details] [diff] [review] Patch v.1 This adds another special case for CSV. It's a reasonable fix, although long term the template should decide what date format it wants. Gerv
If you look at bug 82878. I have a patch that is waiting for a review. Part of the patch pulls out the special date formatting for ICS and uses the Template::Date plugin module. If you apply the patch and leave out the list.rss.tmpl, you will be able to fix this problem just in the template.
> This adds another special case for CSV. It's a reasonable fix, although long > term the template should decide what date format it wants. Agreed, with DiffDate being a filter the HTML template can apply. In the meantime, though, Jason's fix takes us most of the way there and makes your job easier. Making this depend on that bug, which has a patch that is just about done.
Comment on attachment 176389 [details] [diff] [review] Patch v.1 OK - I'll wait for that one. Gerv
Gerv, bug 82878 has landed. We're freezing today, but if you cook up a patch for this before the day is through I'll make sure to review/approve and check in if necessary (i.e. if it's the middle of the night and you're asleep by the time the review and approval come in).
Created attachment 177566 [details] [diff] [review] Patch v.1 Myk: here it is. I think this is probably the best way to do it, given the way the other patch was structured. (I'd have put the raw data in the original column rather than a new one personally, but there you go.) Gerv
Comment on attachment 177566 [details] [diff] [review] Patch v.1 r=myk > I'd have put the raw data in the original column > rather than a new one personally, but there you go. We should do that when we make DiffDate a template filter. I filed bug 286488 on that.
Fixed. Checking in template/en/default/list/list.csv.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.csv.tmpl,v <-- list.csv.tmpl new revision: 1.4; previous revision: 1.3 done Gerv