I use I18n.t('date.formats.default') for date formatting.
The issue is that in different countries there are different date formats, but one english locale.
For example '%m.%d.%Y' fo US and '%d.%m.%Y' for Australia
I need the ideas how to handle with it.
While you might simply use something else for date formats, the easiest drop-in solution would be to store all possible variants in the same string and on retrieval do (assuming the country code is known):
'date.formats.default': 'US[%m.%d.%Y],AU[%d.%m.%Y]'
code = 'AU'
format = I18n.t('date.formats.default')
format[/(?<=#{code}\[).*?(?=\])/] || format
#⇒ "%d.%m.%Y"
The latter || format is needed to support normal format, without brackets.
If you don’t like regular expressions, store the JSON there, containing hash {CODE => FORMAT}, parse it and retrieve the value.
I think it is more convenient way to use different locales.
For example en-AU.yml, en-US.yml, en-CA.yml etc.? Especially i18n supports this.
Australia has different time format too.
Every time you have to take into account all these nuances for each country.
Using different locales simplifies this.
Related
I am trying to parse an ISO 8601 timestamp which looks like this: "20220603T054813Z". My supervisor gave me this timestamp asking me to parse it (she found it on wiki under the ISO-8601 page) but I couldnt find information regarding this type of timestamp anywhere else.
I am trying to parse it using a LocalDateTime instance and using a pre-defined format but I cant find any. Using any of the classes doesnt work neither do the pre-defined formatters for ISO 8601 timestamps. There's no example in the documentation that explains how to handle this particular case and that makes me wonder if this is a valid ISO 8601 case. It does work with my own created format but I am writing a logic to handle ISO 8601 cases without me having to define a custom format, as much as possible. atleast for the ISO 8601 timestamps. Is this a valid ISO 8601 timestamp even? Because usually they have separators for date and time.
Is there a way to handle timestamps like these, which doesnt have any separators or whitespaces, with a pre-defined formatter? Maybe i am missing something. Any help would be appreciated, thanks!
I am using ASP.NET Web Api 2 with Json.NET 6.0.1.
According to ISO 8601, dates should be interchanged in a certain way. I am using the IsoDateTimeConverter() in order to achieve this:
config.Formatters.JsonFormatter.SerializerSettings.Converters.Add(new IsoDateTimeConverter());
But how should "time of day" be returned in a JSON response model?
I cannot find anything for this in the ISO specification.
Should time perhaps be returned as a:
TimeSpan? (with expectation of the user to not use this as a duration representation)
DateTime? (with expectation of the user to drop off the date part)
A custom Time class
There is no standard structure in JSON for containing dates or times (see JSON.org). The de-facto stardard for dates-time values is using a string in ISO 8601 format, as you mentioned. But since there is no official standard it really comes down to what works best for you and consumers of your API.
Using a DateTime object is a reasonable choice because the support already exists in Json.Net and other serializers for converting these to and from ISO 8601 strings. So this would be the easiest to implement. However, users of your API would have to know to disregard the date portion, as you said. You could set the date to 0001-01-01 to emphasize its irrelevance. This isn't so different from the more common situation where you need only a date in your API and the time doesn't matter. Most people just set the time to midnight in this case and let it go. But, I would agree that this approach does seem to have a little bit of a "code smell" to it, given that part of the value is just noise.
Perhaps a cleaner idea is to format your DateTime value as ISO 8601, but then chop off the date portion before returning it. So users of the API would get a string that looks like 14:35:28.906Z. You could write a simple JsonConverter to handle this for you during serialization. This would sort of give you the best of both worlds -- a cleaner API, but you still can work with the familiar DateTime struct internally.
A custom Time class could also work here, but might be overkill, depending. If you do need to go there, you might want to look into a third-party library such as Noda Time, which has classes already built for these kinds of things, and also has pre-built converters for Json.Net.
I would definitely not choose TimeSpan for this purpose. Wrong tool for the job.
I am using a web API that returns values like this:
{
"CNY": 42.0,
"DKK": 31337.00,
"EUR": 6789.01,
"GBP": 6502.00,
"USD": 12345.67,
...
}
I would like to format these values as proper currency values (e.g. for USD, "$12,345.67," for EUR, "6789.01€", for GBP, "£6502.00", for DKK, "31337.00 DKK", etc.) In other words, using the proper symbol ($, £, etc.), but also for some currencies, the symbol comes before the amount whereas for others, it comes after the amount, etc.
The catch is the API I am using only returns ISO4217 country codes ("USD," "EUR," "CNY," etc.) instead of locales. I know NSNumberFormatter has an NSNumberFormatterCurrencyStyle which looks like it does the proper formatting, but apparently the only way you can tell it what type of currency you're dealing with is by handing an NSLocale to its setLocale.
Is there any way to convert from ISO4217 currency codes to locales, other than hardcoding a ISO4217->locale conversion table in my code (which, granted, might work ok since ISO4217->locale mappings probably don't change very often??) Still, I would prefer a way of doing this programmatically if possible.
Of course you cannot map currency codes to locales - with the Euro this just must fail because there are probably 50 locales using Euro.
What you need to do is display the currency according to the locale of the user. Users in Germany, Britain, USA, can all display Euros, for example, and do it in different ways. Each locale can display all currencies.
I have a simple problem in Advantage Database SQL.
I have dates in the format M/D/YYYY and want to convert them MM/DD/YYYY. Normally in SQL Server I would just use a convert(varchar(20), field, 101) but this does not work in Advantage.
What is the format for doing so?
I don't believe there is a simple conversion function like that available. To convert it directly in SQL would probably turn into a fairly messy statement (I think it would require a combination of CONVERT, YEAR, DAY, and MONTH scalars).
If the goal, though, is to force the display of date values in a specific format in the client application, then one possibility might be to specify the date format at connection time. How you do that depends on the client being used. If, for example, you are using a connection string, then you may be able to specify the date format as follows.
Data Source=\\server\share\yourdatapath;...;DateFormat=MM/DD/YYYY;
I have a requirement to handle custom date formats in an existing app. The idea is that the users have to do with multiple formats from outside sources they have very little control over. We will need to be able to take the format and both validate Dates against it, as well as parse strings specifically in that format. The other thing is that these can be completely arbitrary, like JA == January, FE == February, etc...
to my understanding, chronic only handles parsing (and does it in a more magical way then I can use), and enter code here DateTime#strptime comes close, but doesn't really handle the whole two character month scenario, even with custom formatters. The 'nuclear' option is to write in custom support for edge cases like this, but I would prefer to use a library if something like this exists.
I don't think something that handles all these problems exists if the format is really very arbitrary. It would probably be easiest to "mold" your input into a form that can be handled by Date.parse, Date.strptime, or another existing tool, even though that could mean quite a bit of work.
How many different formats are we talking about? Do any of them conflict? It seems like you could just gsub like so: input_string.gsub(/\bJA\b/i, 'January'). Is this part of an import routine, or are the users going to be typing in dates in different formats?
There's a related question here: Parse Italian Date with Ruby