My web application has support for multiple datetime formats, namely yyyy-MM-dd, yyyy.MM.dd, dd/MM/yyyy and MM/dd/yyyy. The two first ones work perfectly, however, when I use the other two formats, the slashes are replaced with dashes in the initial print, which makes them fail validation. However, if I choose a date, it comes out with the correct (chosen) format.
I am using culture sv-SE.
I suspect (with no experience of Kendo UI, but with experience of other date/time APIs) that "/" is being treated as "the culture-specific date separator". If you want "exactly a forward slash, regardless of culture" you may need to escape it.
How the escaping is performed will depend on the library, but often you'd just use quotes, e.g.
dd'/'MM'/'yyyy
MM'/'dd'/'yyyy
As Jon notes in his answer this is about / being a special character in .NET custom date formats.
When working with Kendo this is confusing because it does not use / as a special character.
Using separate format strings client and server side should be the answer, but unfortunately in Telerik UI for MVC (which uses Kendo on the client side) a single format string is used both client and server side with the MVC helpers for Kendo.
For example on a server with a date format "dd-MM-yyyy" (set in Windows regional settings), and a view model:
[Display(Name="Date")]
[UIHint("Date")]
[DisplayFormat(DataFormatString = Constants.DateFormat, ApplyFormatInEditMode = true)]
public DateTime Date { get; set; }
(Constants.DateFormat is "dd/MM/yyyy") then having an editor template ("Date.cshtml"):
#(Html.Kendo().DatePickerFor(m => m)
leads to an initial date display "29-05-2015" and JavaScript errors as it cannot be parsed.
As a work around using
#(Html.Kendo().DatePickerFor(m => m)
.ParseFormats(new[] { "dd-MM-yyyy", Constants.DateFormat}))
the format in the generated HTML is wrong, but the JavaScript will at least be able to understand it. (This should make use of DateTimeFormatInfo.DateSeparator to build the alternative format dynamically of course.)
Related
We are using java.text.NumberFormat class to format the currency values using the method getInstance(Locale paramLocale). Our issue is when we pass es_CO(Columbia) language code it automatically formats it in value 123,00 instead of 123.00. Is there a way to format with dot instead of comma?
I am using Spring platform(hybris)
Please note due to business reasons it is not possible for me to change the locale.
You can use DecimalFormat to have your own format.
Look at this How can I format a String number to have commas and round?
I've been using the MMMM yyyy unicode date time format http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns to generate Month Year. It works great in English and various Latin-based languages. But I'm getting a complaint that the dates are incorrect in Finnish.
The dates that are being generated (by NSDateFormatter on the Mac) are like this:
kesäkuuta 2014
toukokuuta 2014
huhtikuuta 2014
But they should be -- at least, according to a Finnish user of our software:
kesäkuu 2014
toukokuu 2014
huhtikuu 2014 …
I don't know Finnish, so I don't understand how the ta suffix works. Anyhow, does anybody know how to specify some variation on the date formatter that properly formats the date in Finnish, without messing up the rest of the languages?
(I've tried using MMM but that keeps the ta suffix but doesn't change it, AND is abbreviates the months in English, so that's not it.)
According to this IBM page, it looks like MMMM doesn't include the ta. http://publib.boulder.ibm.com/infocenter/forms/v3r5m0/index.jsp?topic=/com.ibm.form.designer.locales.doc/i_xfdl_r_formats_fi_FI.html Hard to imagine it's a bug in Mac OS though.
Or, another Google search shows that IBM had a bug like this: http://www-01.ibm.com/support/docview.wss?uid=swg1OA22258
Anyhow, are there any Mac developers who know Finnish, who understand this issue, and what might be going on?
OK, I reported this as a bug to apple, and I got back a pretty helpful reply, so I thought I would share it here.
Engineering has determined that this is an issue for you to resolve based on the following:
You should never be setting the format "MMMM yyyy" directly in NSDateFormatter if you want to work in various languages; some may have the year first, etc.
If you want a format that uses full month name MMMM + year, you should pass that as a "template" to NSDateFormatter dateFormatFromTemplate: like so:
NSString* format = [NSDateFormatter dateFormatFromTemplate:#"yMMMM" options:0 locale: locale];
For a Finnish locale, this results in the date format "LLLL y" which will produce the proper nominative form of the month names: tammikuu, helmikuu, maaliskuu, etc.
Many languages including Finnish and many Slavic languages use a nominative form of the month name without a day number, and a genitive form or some related form (partitive for Finnish) for month name with day number. NSDateFormatter has both, with MMMM referring to the genitive form and LLLL referring to the nominative form. [NSDateFormatter dateFormatFromTemplate ...] can determine which one to use based on what fields are in the template. So you provide a template specifying either MMMM or LLLL and it will be mapped to the correct form in the resulting format.
Note that in such templates, space and punctuation are ignored; they will be determined as part of the data on correct date formats for the specifed locale.
For more information on pattern character such as MMM and LLL, see
http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
For information on dateFormatFromTemplate, see
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSDateFormatter_Class/Reference/Reference.html#//apple_ref/occ/clm/NSDateFormatter/dateFormatFromTemplate:options:locale:
The problem here is something the developer needs to address in their usage of NSDateFormatter; NSDateFormatter is behaving as intended.
Just noticed, I left out an important part: After getting the format string by passing a template to
[NSDateFormatter dateFormatFromTemplate...]
then that format string is the one that should be set in
[NSDateFormatter setDateFormat:...]
(perhaps that is obvious but it is worth saying)
When using Local Filter (with “contains” operator) Toolbar with jqGrid (latest version), it seems that special characters such as ‘#’ or ‘-‘ (dash) cause the Filter to return NO records.
The same problem exists with other operators as well, such as “Begins With” or “Equal”.
The impact is on fields with content that contains ‘#”, such as emails, or in other text fields like phone numbers.
The problem turns out to be encoded HTML source, so '664-5209' would show up as '664-5209' in the HTML source (using local data source).
And indeed, filtering for '664-5209' would show records with '664-5209'.
The question is whether it is possible to modify the user entered dash to - (and for that matter other HTML encoding) before the filter is executed, and how?
A sample would be helpful.
Im making a url pass in this date format at the very end of the string
2011-11-02T13:59:26.13Z
I can do this
a.sub!(/\..*/,'')
to knock off the .(digit)(digit)Z and work with the time in my controller.
if i put the time in regular format in my url, it works fine. If i put in the specified format above, i get a blank page. If i add the constraint i made (works fine with chopping the end off in the console, I get an routing (no route matches [GET] ...). What should I do to allow to pass in the date format i need (Im using rails 3 if thats important)
The colon is a reseved character and cannot be used within a URL. See RFC 2366 section 2.2
Also, the . (dot) is used to designate a format type in rails, so when this is passed into the router it will try to render a layout for the '13Z' format.
You should encode that time in another format that does not require these characters.
E.g.
20111102135926
Because each field is fixed width it is still easy to parse with a regex.
You could also atime which can be parsed directly in Ruby.
I'm working on a legacy classic ASP interface between our client application and the server. This is not a website, just an intermediate layer in ASP (I know this is not the preferred way of doing things, told you it's legacy and it can - unfortunately - not be changed at this point).
So I'm sending a double value as a parameter on the query string like this:
http:\\localhost\virtdir\myobject.asp?f=function&1=5.25
Now in ASP, I take that value and pass it on to a method on a COM component (myobject is an instance of that COM component) using CDbl to cast the string value to a double:
myobject.DoMethod(CDbl(Request.QueryString("1")))
(Actually, I don't think I have to use CDbl here, as this will be casted implicitly because the COM method takes a double as parameter?)
My problem now is that this doesn't work if in the regional settings of the server a ',' is used as decimal separator. In that case I have to pass "5,25" on the query string to make it work.
As the client doesn't know about the regional settings of the server, is there any reliable way to make sure that a cast to CDbl will always work with the same decimal separator, regardless of the regional settings? Or is there another function like CDbl which does this? Thanks!
you could force the "current culture" using this before calling cdbl
SetLocale(1033)
Session.LCID = 1033