Community
Participate
Working Groups
Currently the format of the $(date) variable in the templates is MMM dd, yyyy. I would like to be able to change this, since I am using it as part of a template when creating new source files. From the news groups, it is suggested that one should be able to change the locale setting at startup time, but that seems to have no effect. Previously (2.x) the format was yyyy/mm/dd. Personally I liked this one better, however, I think it should be customizable. Thanks.
Move to JDT/UI
Moving to text.
It takes the date format of your operating system (locale) settings. There are currently no plans to offer locale customization preferences.
The problem of using the developer's machine's formatter is that if you have a developer in the US commit code and have a developer in Canada commit code, they will be in different formats. So, if you do a build and have a custom processor to do any kind of processing on these date tags, you have no idea how to parse the date. In my concrete case I have a custom doclet that we wrote which traverses the code looking at our own custom tag mytag ${date} I want a uniform date format for the doclet processing, not a locale-dependent one. In other words, I'd like to specify that I want a ${date} in Eclipse, but I want to pass the pattern string to the formatter too. Like this: ${date:YYYY-MM-DD} (inspired by the .NET format syntax - see http://blogs.msdn.com/kathykam/archive/2006/03/29/564426.aspx ) Unfortunately this does not work. Note that the heuristics used when DateFormat.getDateInstance().setLenient(true) is on don't seem to be that good (it fails even across en-ca and en-us). This makes the @date tag and any other that relies on dates absolutely useless for tools that want to traverse the code & do processing based on date values. Java can't parse them in any fuzzy way (infer the format from the value) and Eclipse can't be tweaked to do it in a given standard format for the tools either. We're are stuck. Note that even humans browsing Javadoc may have a problem because the code will have a mix of date formats. Can the support for passing the format pattern string be added, please? Thanks.
.
Unfortunately we can't even use a workaround like ${year}-${month}-${day} because ${year} is a valid variable in the templates but ${month} and ${day} aren't. Can we at least get ${month} and ${day} added since ${year} already is, anyway?
>Can we at least get ${month} and ${day} added since ${year} already is, anyway? No plans to work on this but if you send us a good quality patch we will add it.
I don't know where to start in the wad, to try to add {month} and {day}. What are the classes that contribute {year}? Knowing that would help tremendously.
@see org.eclipse.jface.text.templates.GlobalTemplateVariables.Year
*** Bug 153445 has been marked as a duplicate of this bug. ***
*** Bug 105802 has been marked as a duplicate of this bug. ***
The ${date} variable could be enhanced to accept an argument (similar to other parameterizations added in 3.3M1), e.g. ${d:date(format)}, where format is a pattern for SimpleDateFormat.
*** Bug 169418 has been marked as a duplicate of this bug. ***
Created attachment 98429 [details] Proposed patch to add ${day_of_month} and ${month} templates The proposed patch I attached adds two new global code templates (similar to ${year}): ${day_of_month} evaluates to the current day number ${month} evaluates to the current month number (January = 01) Both numbers are printed using two digits Example: Today, a template using ${year}${month}${day_of_moth} evaluates to: 20080502
To be looked at during 3.5.
Patch to be assessed during M6.
I don't like the patch as it introduces the same problem that this bug wants to solve: it hard-codes the formatting by adding a '0' ;-) The correct fix is outlined in comment 12.
The date variable should also take a locale string as optional second argument, i.e. the documentation should define it as ${id:date(format[,locale])} The locale should be a java.util.Locale identifier, separated by '_', see Locale#toString().
*** Bug 303336 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > *** Bug 303336 has been marked as a duplicate of this bug. ***
Comments 15 and 16 indicate this will be looked at in 3.5 and M6 respectively. This was back in 2008. 3.5 does not appear to addressed this issue. Is there an update on when it may be addressed?
>Comments 15 and 16 indicate this will be looked at in 3.5 and M6 respectively. Which we did, see comment 17. No work planned until we get another patch.
Hello together, I wish I could support you on this bug fixing but I need some help to help us: 1/ I do not have the sources of the eclipse platform. Does an how to FAQ, etc exists? Since I am using Ubuntu 10.04, I will do my development based on the platform 3.5 (not 3.6). But if accepted I will submit it also for 3.6 2/ Please confirm the following specifications: Use of the already existing variable ${date} 1/ Replaced by ${date(format)} (format) is optional ie: use example 1 ${date} ==> actual value use example 2 ${date(yyyy-mm-dd)} ==> 2011-04-04 if format does not exist, the current version will be used. format will be buid on the use of the following keywords: YEAR: y yy yyy yyyy : The expected numbers of characters (ie y=1; yy=11; yyy=011; yyyy=2011) Y* : alternative use, not defined yet ==> I can also do y= 2 char; Y= 4 chars MONTH (just for Dani MEGERT): m : Month number as short as possible ( 1 if january ; 10 if october) mm : Month number with 0 pre-completion (01 if january; 10 if october) M : Month short name in the locale used by eclipse (if this concept exists) MM : Month full name in the locale used by eclipse DAY: d : Day number as short as possible ( 4=4th day ; 10=10th day) dd : Day number as short with 0 pre-completion (04=4th day ; 10=10th day) ==> if someone want 0024 for the 24th of january he will be able to do it using 00dd Any other character would be printed out like found in the string To print out 'm' 's' 'd' or '\' the use of '\' will be used to escape For escape char, if '\' does not fit with the used standards, please tell me which char must be used. I will probably need some support especially about the coding rules of the project (documentation, delivery process, bug management). Please do not tell me RTFM but tell me instead where TFM takes place.
(In reply to comment #23) > Hello together, > > (...) > > I will probably need some support especially about the coding rules of the > project (documentation, delivery process, bug management). Please do not tell > me RTFM but tell me instead where TFM takes place. Finally I found the info: http://wiki.eclipse.org/Platform_UI/How_to_Contribute
The spec is in comment 12 and comment 18. We won't accept a complicated patch that invents date formatting again. See comment 9 for an entry point to start coding. The code is in org.eclipse.text in :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
(In reply to comment #25) > The spec is in comment 12 and comment 18. We won't accept a complicated patch > that invents date formatting again. > > See comment 9 for an entry point to start coding. The code is in > org.eclipse.text in :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse Well actually, the date format of Class SimpleDateFormat is something I had in mind even if I did not know it. Okay for that (it will even make the things easier since it is already available, just an interface to create between template and java ...) What is still not clear for me is which one of the 2 must be used? ${d:date(format)} and ${id:date(format[,locale])}
(In reply to comment #26) > What is still not clear for me is which one of the 2 must be used? > ${d:date(format)} and ${id:date(format[,locale])} Why do you think the older comment would win over the newer one?
*** Bug 347399 has been marked as a duplicate of this bug. ***
(In reply to comment #26) Romain, have you been able to work on this issue? If not I would fix it.
(In reply to comment #29) > (In reply to comment #26) > Romain, have you been able to work on this issue? If not I would fix it. Hi Thomas, unfortunatly I do not have time to do this fix (new job, etc...) and I do not plan to work on that (I do not know the Eclipse architecture and would require a lot of time for this fix). I will thank you if you do it! Good luck and I hope one day I will come back to help the team.
I have created a patch that implements the proposal in comment 18.
Created attachment 213533 [details] Patch as described in comment 31.
Thanks for the patch Thomas. It works, but needs some polish: - It should not fail with exceptions when the format or locale is wrong. Instead, it should just delegate it to the super method. - The existing default format must be kept if no arguments are given. - You should not use Locale.getDefault(), if no locale is specified. - The patch misses to set whether the variable is ambiguous or not. - The description of the variable must be improved and explain what the valid formats are. - The documentation (F1) needs to be updated. See org.eclipse.jdt.doc.user/concepts/concept-template-variables.htm - Each changed file needs an entry in the copyright, e.g. Dani Megert <dani@eclipse.org> - this is a bug - https://bugs.eclipse.org/75981 - Please use the same formatting style as in the existing code.
I would like to take this up and finish it. Can this be assigned to me. I am new to this so not sure if the bug needs to be assigned to me before i can work on it
(In reply to Pramod Goyal from comment #34) You can just attach a patch here. We usually don't assign a bug to an external contributor unless it's a bigger project and we've already seen some promising results.
Created attachment 235875 [details] Fix as per Dani's comment
Can someone please let me know how to update the document for this ? As per Dani's comment we need to update the document: - The documentation (F1) needs to be updated. See org.eclipse.jdt.doc.user/concepts/concept-template-variables.htm However i couldn't find the concept-template-variable.htm anywhere
I guess he wanted the documentation in the JDT plugin to reflect the changes: http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Fconcepts%2Fconcept-template-variables.htm Try looking in for the HTML file in the org.eclipse.jdt.doc.user plugin. Note that the bug/feature itself relates not to org.eclipse.jdt.*, but to org.eclipse.text!
Use File > Import... > Plug-ins and Fragments, and select "Projects from a repository" to import the org.eclipse.jdt.doc.user bundle. Nag in bug 395143 if you don't like the wrong default location for the cloned repo.
Created attachment 235894 [details] Document update Adding a patch for document update. Please review both this and previous patch and let me know your comments.
Thanks Keller/Phil. Submitted the updated document
Sorry i am new to this ,can some one tell me what are the next steps to close this ticket.
(In reply to Pramod Goyal from comment #42) > Sorry i am new to this ,can some one tell me what are the next steps to > close this ticket. We will have to review the patches and comment on them, but currently we are very busy working on Java 8 support for Eclipse. Stay tuned!
Any progress on this? I understand that everybody is busy, but this is just a small patch. Should be relatively easy to OK it.
(In reply to Pramod Goyal from comment #36) > Created attachment 235875 [details] [diff] > Fix as per Dani's comment I see that you've added the following copyright info: * Pramod Goyal: pramod.goyal@gmail.com - this is a bug - https://bugs.eclipse.org/75981 How much is your code and how much is from Thomas, who contributed the initial patch? If it uses the code from Thomas, then he also needs to - be added to the copyright header - sign the CLA - confirm in this bug that he wants to contribute that code by stating: "This contribution complies with http://www.eclipse.org/legal/CoO.php" Also, please replace "this is a bug", with the bug summary from bugzilla.
I managed to sign the CLA but I think the latest patch does not use my code. So this should be fine.
I was just looking for this, found this bug, and judging from the above comments, it seems like everything should be in order to just include the patch?
I haven't checked the source code recently, but the last few builds seem to have this functionality already... For example this is in my current C++ 'file' comment (C/C++ > Code Style > Code Templates > Comments > Files) and works just fine: /// @date Created on ${id:date('dd MMM YYYY')}
New Gerrit change created: https://git.eclipse.org/r/58196
(In reply to Eclipse Genie from comment #49) > New Gerrit change created: https://git.eclipse.org/r/58196 I have given this bug a try. I have taken the existing patch (attachment 213533 [details]) with some modifications. I have added a Unit Test for the different cases. All authors are mentioned in the commit message. I hope that putting it into a Gerrit patch will ease the code review process. I will prepare a second change with the patch proposed in attachment 235894 [details] (for the documentation).
(In reply to Markus Keller from comment #18) > The date variable should also take a locale string as optional second > argument, i.e. the documentation should define it as > > ${id:date(format[,locale])} > > The locale should be a java.util.Locale identifier, separated by '_', see > Locale#toString(). I had a look at the Locale Javadoc. I think that the locale should conform to the "IETF BCP 47" specification. It seems to be a standard: "Tags for Identifying Languages". See: Locale#forLanguageTag(Sring) http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#forLanguageTag%28java.lang.String%29 My understanding is that the main difference is that the separator is '-' and not '_' (example: 'fr-FR' and not 'fr_FR')
New Gerrit change created: https://git.eclipse.org/r/58275
(In reply to Jeremie Bresson from comment #51) > See: Locale#forLanguageTag(Sring) To use this method, Bug 478673 (Move platform text to Java 1.7 BREE) must be solved first.
(In reply to Jeremie Bresson from comment #53) > (In reply to Jeremie Bresson from comment #51) > > See: Locale#forLanguageTag(Sring) > > To use this method, Bug 478673 (Move platform text to Java 1.7 BREE) must be > solved first. Don't use that method. We should use what's known to Java developers and that's the usual Locale format, e.g. de_CH.
As discussed here and on Gerrit the last version of this patch (Patch Set 5 on Gerrit) does not use the Java 7 Method: > Locale#forLanguageTag(Sring) As suggested, the replacement was to use: > com.ibm.icu.util.ULocale I remove the dependency to Bug 478673.
I've reviewed both changes. Only some minor issues need to get fixed before they can be merged.
Gerrit change https://git.eclipse.org/r/58196 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=b15d692552891c96627cde1a8652ae9216b57e99
Gerrit change https://git.eclipse.org/r/58275 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=70e775b9e23132bb9ef9be65ecb2dfbff7353e9f
I've added the following to the info for 'time' and 'year' variable: Use the 'date' variable if you want to specify the format. And added an entry to the 4.6 M5 N&N.
Opened Bug 486748 for an improved description of the date variable.
