| |
Results |
|
Date validation is not happening if user has set German Locale and date format
|
- submit an item into any project that contains a date field. Enter and invalid date (for example 32.04.2000)
|
|
|
|
SBM quietly replaces invalid dates with the inaccurate value 30.01.1900. if the date format is set to dd.mm.yyy
|
However if the Date/Time field format is 'dd.mm.yyyy' the above error message will not be thrown in such a case and instead the field will regardless of the locale be filled with the inaccurate value of '30.01.1900'
|
|
|
|
Date selection of Scheduled transfers not functioning as Locales set to US date format
|
Problem seems to occur because the date format is US. Consequently the file transfer fot 0/7/11/02 thinks its for November and not July. If you use the 'Today' button to select the date it correctly sets it as July .Only problem is the transfer still does not run.
|
|
|
|
Date format in article for Knowledge Management in SRC does not use locale set in SBM
|
In an article in the Knowledge Management in Serena Request Center the date format from SBM is ignored and it is always shown is US format . To reproduce: (1) Set date format in SBM to dd/mm/yyyy
|
|
|
|
Dates within email notifications to users that have 'use date/time format from locale' set are incorrectly displayed
|
Dates within email notifications to users that have a datetime display setting of 'use date/time format from locale' set are incorrectly displayed e.g. submit date. The notification server cannot know what the locale of the users machine is and therefore would understandably revert to a setting on the server. However, the locale of the server is set to a non-US locale e.g.UK the date is still displayed in US format - mm/dd/yyyy.
|
|
|
|
Report filter date keywords do not work for most locales
|
(Error:'-11' for field UBG_ISSUES.TS_EST_DATE_TO_FIX is invalid format ) and ((UBG_ISSUES.TS_PROJECTID IN (2,6,8))) order by TS_PROJECTS.TS_SEQUENCE, UBG_ISSUES.TS_ISSUEID Incorrect syntax near 'Error:'. Statement(s) could not be prepared.
|
|
|
|
Relational Field Value Display Format does not take locale into account
|
However, when the value of the relational field is displayed as part of a search field or drop down field, for example during a transition or item update, the date format will fall back to the US format and will be displayed such. This however is just temporary, and once the item is saved, the display is using the regular date format again.
|
|
|
|
RLC: Timeline view breaks if user changes date format settings in profile
|
Steps to reproduce: - open the settings in the current users profile and go to Locale then check the setting of the date format - create a new release train and set the schedule dates and start the train
|
|
|
|
AppScript/ModScript use incorrect locale for display of dates after upgrade to 11.7.1
|
If you find after upgrading to 11.7.1 that your date formats in appscript or modscript suddenly switch from your selected locale to one of the English varieties this is an unintended consequence of a change to resolve other locale issues. A fix will be available in a later release. For specific instructions on how to work around this, contact Support
|
|
|
|
GetFieldValue() does not apply user's locale when referencing a subrelational date field
|
In certain scenarios the getFieldValue Javascript function returns dates in the default format instead of the date format selected by the user. For example the regional settings are set to use a date formatting of dd/mm/yyyy so a date of 07/10/2015 should be returned as 07 October 2015, however for this particular field only the returned date is Fri Jul 10 2015 00:00:00.
|
|
|
