Bugzilla – Bug 1376
Enh: "Naming newly recorded tracks" does not respect system time/date format
Last modified: 2018-08-20 11:51:33 UTC
For example system date and time of 1:28 PM 14 April 2016 shows currently in Track Name as "2016-04-14_13-28-59". Or, at least provide a checkbox opposite System Date for DD-MM-YYYY and opposite System Time for H-MM.
The date/time format is based on the ISO format, but made "filename safe". I'm -1 for the proposed enhancement and I'm confused why this is considered less of "an abuse of bugzilla" than bug 1380.
(In reply to Steve Daulton from comment #1) > I'm confused why this is considered less of "an abuse of bugzilla" than > bug 1380. Because you asked that here, I must answer here. The reason is that bug 1380 was an "opinion" about wording presented as a repeatable bug and we have a policy not to put wording issues on Bugzilla. This is logged as an "enhancement" issue which are by nature open to opinion, and subject to being practical after being fairly investigated. I posted the "enhancement" because there have been three "complaints" from European users that the new feature for displaying what is described in Preferences as "System Date" and "System Time" in Preferences is not the OS date/time format but (to the user) looks like US date and time. In other words, the users were describing the behaviour as a "bug". It isn't a bug because it does what the Manual says, but IMO the behaviour does greatly limit the value of the feature for those outside the US if the user has to manually rename after recording.
(In reply to Gale Andrews from comment #2) We can put feature requests onto Bugzilla if you want, but that's not what bugzilla is designed for and it would add a considerable amount of clutter. Personally I would prefer that we had a separate tracking system for feature requests, but as we are currently using a wiki page for that purpose, that would be a more appropriate place to log this "enhancement". > IMO the behaviour does greatly limit the value of the feature for those > outside the US Imo that's a gross exaggeration. Neither Peter or myself find the ISO time/date format "greatly limiting", and we are both outside the US. I don't see how using the ISO time/date format is any more "limiting" than any of the other dozens of possible day/date/time formats that we 'could' add. To give this issue credence as an "issue" that needs to be tracked, we would also need to track an "enhancement" for adding the full day name (eg "Monday") and an enhancement for adding the short day name (eg "Mon"), and for adding decimal places to seconds, and for adding the month name, and for adding the week number, and more. Note that if we used the actual system format for the date, then in the majority of cases it would not be a valid file name. Fixing that, if we did that, would be a valid enhancement to be tracked on bugzilla. Also note that Audacity allows arbitrary text to be used as track names. The way that I would prefer to address your "feature request" would be to make an optional plug-in available. Surely that would belong on the wiki "Feature request" page and not here? > there have been three "complaints" from European users that the new feature > for displaying what is described in Preferences as "System Date" and > "System Time" in Preferences is not the OS date/time format but > (to the user) looks like US date and time. I read all users posts on the forum and all feedback@messages and I've seen none of those alleged complaints. This feature request would therefore be very low on my list of priorities. Responding to your comment 2 here is higher on my priorities because inefficiencies in how we use or abuse bugzilla affects me directly by wasting my time.
(In reply to Steve Daulton from comment #3) Feature requests go on Bugzilla, IMO, if it is something the users are reporting (wrongly) as "bugs" or if the feature lack causes inconvenience or confusion. They are enhancements that have "impact" if not addressed, like bug 551. Otherwise, I don't add them. One of these did come from the Forum, or somewhere online, which is what tipped me into logging the enhancement, though as yet I have not been able to find it. If I do find it I will post the URL. The point that is being made is that if large numbers of files are exported and the computer file system and hence the large number of existing recordings are DDMMYYYY, new files that Audacity exports as YYYYMMDD have to be renamed. It is in one sense no worse than it was before, but it is no better either, so to the users concerned it seems just a "wasted feature". Apart from that, the label in Preferences has been shown to be ambiguous. If I was in your shoes, Steve, I would be grateful for user feedback. It is not my feedback as I don't use or care about this feature. The (3) "votes" will sometime get onto Feature Requests and be counted. *If* only a few more votes are accumulated, then perhaps this could be closed as not of sufficient importance. There would be no other reason to close it, because other enh's have been implemented by other developers, despite your personal opposition.
(In reply to Gale Andrews from comment #4) > Apart from that, the label in Preferences has been shown to be ambiguous. Ambiguous in what way? > If I was in your shoes, Steve, I would be grateful for user feedback. I am. I'm very grateful to the dozens of off-list messages that I receive, but I wouldn't want to push hearsay as policy. > It is in one sense no worse than it was before which implies that in some other sense it is worse than before. In what sense is it worse than before? Perhaps we can fix that.
(In reply to Gale Andrews from comment #4) >The point that is being made is that if large numbers of files are exported >and the computer file system and hence the large number of existing recordings >are DDMMYYYY, new files that Audacity exports as YYYYMMDD have to be renamed. The key reason for preferring the ISO format is that it makes the files readily sortable by date order based on the filename - not possible if you use DDMMYYYY format, as Koz is fond of pointing out to users on the Forum.
(In reply to Steve Daulton from comment #5) >> Apart from that, the label in Preferences has been shown to be ambiguous. > Ambiguous in what way? Already answered in http://audacity.238276.n2.nabble.com/Bug-1376-invalid-td7574870.html . In other words, it is indeed the time and date the system is at, but it is not the format for time and date set in the system, which the label implies unless you know otherwise. > I'm very grateful to the dozens of off-list messages that I receive, but I > wouldn't want to push hearsay as policy. Not all feedback is made publicly. We should not ignore it if made offlist and appears to be genuine. IIRC, you yourself lengthened the Edit Menu in direct response to a strongly worded offlist message you received that you were convinced by. >> It is in one sense no worse than it was before > which implies that in some other sense it is worse than before. I did not say it was worse than before, I said it was "not better" if you want DDMMYYYY. Either you don't write the date, or you must rename. (In reply to Peter Sampson from comment #6) > The key reason for preferring the ISO format is that it makes the files > readily sortable by date order based on the filename - not possible if > you use DDMMYYYY format, as Koz is fond of pointing out to users on the Forum. No-one is asking to remove the ISO format. As I already agreed, it's the only reasonable choice if we can only offer one and must hard code it. It just isn't useful if you already have thousands of files named as DDMMYYY (which you can easily sort by date order) and you have any reason at all based on your locale or equipment for needing DDMMYYYY. I note that the Timer Record dialogue does respect the system date format, even the exact short format chosen. It's the date that seems to be the "problem", according to these three complaints.
(In reply to Gale Andrews from comment #7) Surely it's the same "problem" for users that have "thousands" of files that are dated as: yyy-mm-dd yyyy_mm_dd mm-dd dd-mm dd-ww-yy dd-ww-yyy dd_mm_yy dd_mm_yyyy ddMonthyy ddmmyy Number of sec since January 1, 1970 dd-hh-mm etc. One solution could be to have symbols representing the elements of date and time like this: http://www.cplusplus.com/reference/ctime/strftime/ but personally I think that's too complicated.
I am going to close this as WONTFIX
