re: Formatting dates with JavaScript VIEW POST

FULL DISCUSSION
 

Hi Jesse, I truly believe your intentions are good and it's a great article as an insight about how formatting dates might work in practices but I have to disagree with some of the wording.

I'm definitely in favor of using simpler solution instead of bringing in a full library to solve a seemingly simple problem but I'm going to play the devil's advocate here and say this: dates are not a simple problem. Which is why we end up with these many libraries (too many TBH :D).

If you're not picky about how dates and times will be displayed, this can work well in many cases, but it depends on each user's operating system, and which locales are installed on their devices

Sure, unless you use the same locale for each user, which is basically what you're doing here:

function getMonthName(date) {
    const months = [
        'January',
        'February',
        'March',
        'April',
        'May',
        'June',
        'July',
        'August',
        'September',
        'October',
        'November',
        'December'
    ];

    return months[date.getMonth()];
}

I'm not an English native speaker and I live in a country of non native English speakers, so I have to take into account that if I'm working a UI for the local market displaying September won't cut it.

I might harcode my version of the list of months, but as you surely know, building untranslatable apps can give you headaches down the line if you ever have to cater more than one market. But even if you don't, I'm 100% sure you'll find people in each country that have a locale set different from the one tied to the language spoken by the majority (and there are countries, including Canada that have more than one official locale).

So whatever the app is built in, I have to think about the possibility that I might need to display the name of the month in more than one language.

With your example I could hard code all the possible lists or choose a set of "supported languages" but the Intl API gives me that for free (without a library!), why not use it?

> new Intl.DateTimeFormat('default', {"month": "long"}).format(new Date())
"April"
> new Intl.DateTimeFormat('fr-CA', {"month": "long"}).format(new Date())
"avril"

If you really want to make sure that everyone is seeing a month name in English you can switch default (as you see I keep my browser in English even if it's not my first language) to en-US, en-CA or equivalents.

We could even make a case that respecting the user's wishes (how they want the dates/times to be formatted) also improves the user's experience.

I hope I've provided you with all the tools and techniques you might need to format dates and times.

You're seemingly encouraging people (correct if I'm wrong about this) to give away with internationalization features that are builtin in browsers that took so much time to be finally standardized so that they can use a set of custom made functions? This is the part I disagree with the most. You brushed them aside quickly and I fear that someone down the line will read the paragraph "What about the Internationalization API?" and dismiss the whole API because your functions are simple to understand and well documented thanks to this article.

I truly think you have good intentions and I enjoyed your explanation of the shortcomings of the builtin JS functions (one day I'll write something about the stupid shortcomings of Python's functions eheh) but I think your article should make clear that Internationalization it's an important issue, even if you don't actually plan to use it in the beginning, and that these are good examples of how date formatting might work, not "all the tools you might need".

 

You're right, the Internationalization API would probably be the preferred approach in most cases. This article is showing how to do it manually if that's what you choose or prefer to do.

code of conduct - report abuse