Develop Reference

Differences in currency formatting using Number.toLocaleString()

I've been looking into locale aware number formatting for javascript and found that Number.toLocaleString and by extension Intl.NumberFormat appear to be good solutions for this problem.
In particular I'd prefer building on top of already implemented abstractions for locale specific formatting rather than reinventing the wheel and coming up with one more solution to an already solved problem.
So I've called Number.toLocaleString on some different javascript environments and found that currency formatting seems to have changed:
(5).toLocaleString('fr-CH', {currency: 'CHF', style: 'currency'});
// Node v10.15.1: 'CHF 5.00'
// Node v12.1.0: '5.00 CHF'
// Firefox 66.0.2: '5.00 CHF'
// Chrome 73.0.…: '5.00 CHF'
// Safari 12.0.3: '5.00 CHF'
// IE 11: '5.00 fr.'
IE 11 is different than the rest, but it doesn't surprise me given its age.
What surprises me is that the formatting for CHF in fr-CH seems to have changed between node versions 10 and 12.
For comparison I had a look at the glibc LC_MONETARY settings for fr_CH and found that it seems to place the CHF before the amount at least about 1997. This makes it particularly confusing that the position of CHF seems to be different for most current browsers.
I would like to know and understand:
Why are the positions of the CHF different in these cases?
I know that this can depend on the available system locales or the browser. But the change between node versions seems to indicate a more recent and voluntary change to me.
Is there a correct way to place the CHF or are both choices acceptable for CH, or more specifically fr-CH?
For this it would be beautiful to have an actual source like a paper or research database rather than hearsay or anecdotes.
Update (2019-05-16):
In reaction to my partial answer I'd like to specify:
The formatting decision for fr_CH is given as currencyFormat{"#,##0.00 ¤ ;-#,##0.00 ¤"} in commit 3bfe134 but I'm still missing a source for the decision and would love to know about it.

So I've checked out the v8 source to see if I can find where the behavior of Number.toLocaleString is defined.
In builtins-number.cc I found the BUILTIN(NumberPrototypeToLocaleString){…} which uses Intl::NumberToLocaleString(…).
This led me to intl-objects.cc which implements the Intl::NumberToLocaleString using an icu::number::LocalizedNumberFormatter.
Since v8 uses icu I checked out the source to continue my search.
My first tries to find the source of the number formatting led me to look at decimfmt and numfmt first, but I somehow kept loosing the trace.
Then it dawned on me that it would likely make sense to keep the format definitions somewhat separate from the rest of the code. By looking around the website and the source more I finally found icu4c/source/data/locales/de_CH.txt and icu4c/source/data/locales/fr_CH.txt.
de_CH.txt has currencyFormat{"¤ #,##0.00;¤-#,##0.00"}.
fr_CH.txt has currencyFormat{"#,##0.00 ¤ ;-#,##0.00 ¤"}.
Now using git I found the commit that first introduced the currencyFormat for fr_CH (3bfe134) 19 months ago.
This is plausible to be between node v10 and v12.
I can also see that it it would make sense to fallback on de_CH before the curreencyFormat was added to fr_CH and therefore see that the format would change the way it did.
The commit mentions CLDR 32 alpha, and I found the CLDR charts version 32.
However I'm currently not able to figure out where the chart is located that defines the currencyFormat for fr_CH.
I feel that by finding the change to the fr_CH currencyFormat I found and understand the change that leads to the change of behavior between different node versions.
As of now I don't understand why glibc and icu have differences here, but that is something I can ask around in the context of the specific projects for.
I'm under the impression that I'm still missing the specific decision or data-point which led to the currencyFormat implementation - if I find it I shall add it here and be satisfied.
Update 2019-05-18:
The CLDR 32 data can be fond in the download section under cldr.unicode.org.
From there I could download the cldr-common-32.zip which included the file common/main/fr_CH.xml in which the currency format is defined like this:
<currencyFormats numberSystem="latn">
<currencyFormatLength>
<currencyFormat type="standard">
<pattern draft="contributed">#,##0.00 ¤ ;-#,##0.00 ¤</pattern>
</currencyFormat>
</currencyFormatLength>
</currencyFormats>
Via cldr.unicode.org I also found the survey-tool which is used to decide on these matters and to document the outcomes of such decisions.
In the Number Formatting section for fr_CH I could then see the decisions source:
Update 2019-05-21:
So out of curiosity I've asked about this on the libc-locales list as well as on the closest ticket I could find on the unicode-org ticket system.
This prompted me to investigate further and when researching this with a friend we stumbled upon the cldr repo on Github which is focused on CLDR data rather than having CLDR related data in it like icu has.
We found that commit c5e7787 introduced the first change that led to the CHF being placed after the number rather than before it and trough that commit became better aware of two tickets.
These tickets are CLDR-9370 and CLDR-10755, the second of which is a follow up that clears up some formatting.
While on the surface CLDR-9370 seems to mostly discuss the decimal separator, the currency symbol placement is discussed as well.
One of the sources given is a typography guide (pdf) published by the CERN which gives detailed instructions on the ways to write numbers.
For CHF the guide notes:
Using google translate this translates to:
Writing sums of money
The number is written in three-digit increments separated by a
non-breaking space (no point or apostrophe of separation), and is
followed (and never preceded) by the indication of the currency is
long or abbreviated. For name abbreviations currency, we use the ISO
code.

String translation with dynamic text and inputs

I am working on front-end only React application and will soon be implementing internationalization. We only need one additional language... at this point. I would like to do it in a way that is maintainable, where adding a new language would be ideally as close as possible to merely providing a new config object with translations for various strings.
The issue I know we will have, is that we have dynamic inputs inside of sentences as demonstrated below (where [] are inputs and ** is dynamically changing data). This is just an example sentence... lots of other similar type things elsewhere in the app.
I am [23] years old. I was born in [ ______▾]. In 2055 I would be *65* years old.
We could break out 'I am', '*age input', 'years old. I was born in', '*year dropdown'. etc. But depending on the language, word order could be changed or an input could be at the beginning of a sentence etc, and I feel like doing it in that way would make for a really weird looking and hard to maintain language file.
I'm looking to know if there are common patterns and/or libraries we can use to help with this challenge.

A react specific library is react-intl by yahoo. Which is part of a larger project called FormatJS which has many libraries and solutions for internalization. These and their corresponding docs are a good starting point.

difference between moment js functions and javascript date functions [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Actually i am thinking about to use moment.js in my new project.because my new project is a employee working sheet application.
I read the moment.js documents.
We can get the current date by using the below code in moment.js
moment().valueOf();
We can get the current date by using javascript
new Date()
The both are giving same result. with same speed (so no performance issue )
also formatting, get methods and set methods are already has javascript. then why i go to moment.js?
Please give me some explanations about the difference's. And let me know which one is best for my new project.

Moment.js
A lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates.
Reason why we use Moment.js - Many web applications today, especially social ones, deal with the concept of time. They are usually employed to sort events or posts, or to mark the moment in which something happens. You can think of your Twitter timeline or your GitHub news feed. JavaScript has a Date object that you can use to manipulate dates, but it often doesn’t have all you need in your web applications
The Moment.js library not only parses dates from strings, but it may also be used to validate, manipulate, and format dates. It supports internationalization, which is so important with dates, as well as human-friendly formatting like "Last Friday at 9:48".
These are all good things for sure, but today's order of the day is date parsing, so let's get into how that works.
Moment.js creates a wrapper for the Date object rather than extend it. To reference the wrapper object, simply call the moment() getter function. The Moment prototype is exposed through the moment.fn property, so you can add your own functions to it if you are so inclined.
Courtesy of
Managing Dates and Times Using Moment.js
A Roundup of Popular JavaScript Date Parsing Libraries: Moment.js

Moment.js is convenient when you want to manipulate Dates.
An Example for moment is given below
moment()
.add(7, 'days')
.subtract(1, 'months')
.year(2009)
.hours(0)
.minutes(0)
.seconds(0);
moment().endOf('day').fromNow();
But if formatting, getting and setting is all you need, you might not need a library for that.

Obviously, I would suggest to go with moment.js. It is one of the most popular Date parsing library.
moment.js has a various inbuilt function's available which is easy to use.
It will save your development time.
Manipulating and parsing dates is very easy.

It comes down to what you're trying to do.
MomentJS provides an API that pretty-much wraps the native Date object, which is why you call .valueOf. new Date is simply giving you the native Date objects (and to manipulate it using moment, you'd need to pass it to its constructor).
I would say general rule of thumb:
If you're creating a date for use on the site or as some kind of UI element, use Moment.
If you're storing a date back to a service layer, use Date.
If you're working in a method that's manipulating the date, use Moment; If that then needs to be passed to another service layer, call .valueOf and save it off.
Moment is great for the UX, but isn't a "standard" (and therefore wouldn't be ideal for serialization/storage).

Moment.js has a good support for adding, subtracting, advanced formatting, finding differences between two days. Also it has internationalization support so you can convert to any language very easily.

just like any library comes with a purpose to aid with something and make it easy to work. momemt.js makes working with dates PAINLESS.
working with dates considering the timezone and formats factors etc is very difficult, but moment.js makes it a breeze to work with dates.
read more here

Chronic for Javascript?

I'm looking for something like the Ruby Chronic library, but for Javascript. The main things I need to be able to do is parse natural time entry, not dates. For example:
Typing Would Give
------ ----------
8a 08:00
8:30p 20:30
8:01 AM 08:01
21:22 21:22
noon 12:00
midnight 00:00
I could write it myself, but before I go off and tackle it, I wanted to know if there was something already available.
I'm using jQuery already, so if there's a plugin, that would be hoopy too.
Thanks!

In place of my previous answer recommending Date.js, I'd like to update my answer by recommending Moment.js instead. It's a stable project that is still under active development. In addition, it is far more feature-filled and has a superior API. :)

Date.JS is a wonderful JS library for working with dates and times.

Comparison support for Ruby Chronic.com date and time input formats.
Check this out
http://www.datejs.com/test/ruby_chronic/index.html

Formatting and pretty printing dates with jquery

I need to display dates in a couple different ways in an app built with jquery.
In some situations, I need the typical "yyyy-mm-dd hh:mma" type of formatting, with all of it's different permutations. In other cases, I need to show dates "pretty printed" similar to how StackOverflow does them:
5 seconds ago
12 minutes ago
3 hours ago
yesterday
2 days ago
My application already uses JQuery UI DatePicker which includes a formatDate() function, but as far as I can tell, there is no way to use it outside of the datepicker. I want to format dates that aren't associated with a datepicker. Is it possible to do this using DatePicker?
The DateJS library can parse dates like "12 minutes ago", but as far as I can tell, it cannot take a Date object and format strings like this. It can format the typical "yyyy-mm-dd" types of formats. This library seems pretty heavy as well.
John Resig's Pretty Dates looks like it can provide the pretty printing ("2 hours ago"), but it doesn't do the standard formatting.
Is there not a single plugin that can do all of this? Is there a way to leverage the DatePicker code so I don't have to load multiple codebases that do the same things?

http://timeago.yarp.com/

Check out prettyDate.
It's made by the same guy that does the jQuery Validation plugin.