Janeiro Fevereiro Março Abril

Working with Portuguese Month Names in Real-World Systems

The Portuguese months are straightforward if you never have to touch them programmatically. January through April are janeiro, fevereiro, março, abril. That's it. The problem starts when you're building a multilingual application that ships to both Brazil and Portugal and the dates don't sort correctly, or when you're parsing legacy data where someone used "Jan" for everything and now your parser is broken. I spent about three weeks debugging an issue where our event system was dropping all February and March entries in the Brazilian deployment. Turns out the database was storing months as integers 1–12, but the frontend was trying to map them against a hardcoded English-to-Portuguese dictionary that only had one entry for "Fevereiro" and the locale detection was pulling the European Portuguese variant at runtime, which happened to fail on certain devices. I don't even remember the exact fix because by then I'd just switched to using Intl.DateTimeFormat with explicit pt-BR and pt-PT tags and stopped trying to roll my own month map. It took maybe four hours instead of three weeks.

janeiro fevereiro março abril

If you're just listing them for reference, here are the first four months with their common abbreviations and a note on how they behave in practice: janeiro (jan) — 31 days. In Brazil this is peak summer, so marketing campaigns and e-commerce traffic are high. In Portugal it's cold and wet. Not relevant to your code, but relevant if you're building seasonal logic. fevereiro (fev) — 28 or 29 days. This is where most people get tripped up. If you're doing date arithmetic with February and not handling leap years properly, your code will fail every four years. I once saw a billing system that under-charged customers by one day in leap years because someone used new Date(year, 2, 0) in JavaScript, which actually gives you the last day of February, but they had the month index wrong and it was returning March 0, which rolls back to the last day of February anyway, so it worked by accident. Don't rely on accidents.

março (mar) — 31 days. Same abbreviation as March in English, which causes confusion when you're doing string matching. If you parse "mar" and assume it's March in English, you'll map it incorrectly in a Portuguese context. Use the full name or a language-aware parser. abril (abr) — 31 days. No special edge cases, just a regular 31-day month. April Fool's Day exists in both Brazil and Portugal but has less cultural weight than in English-speaking countries.

Common Pitfalls and How to Avoid Them

The biggest issue with Portuguese month names isn't the names themselves, it's the surrounding ecosystem. Here are the things that actually bite people: Date parsing libraries assume English. Most JavaScript date parsers, Python's strftime / strptime, and PHP's DateTime::createFromFormat will accept "janeiro" only if the locale is set correctly. Set the locale at the system level or pass it explicitly. If you're using a framework, check whether it auto-detects the user's locale or if you have to wire it yourself. I've lost count of the number of support tickets caused by a missing LANG=pt_BR.UTF-8 in a container environment. Sorting by month name instead of number. Alphabetical sorting of Portuguese month names gives you abril, fevereiro, janeiro, março. That's obviously wrong for any calendar view. Always store months as integers internally and convert to names only at the display layer.

Abbreviation inconsistency. In formal documents, Portuguese sometimes uses "Jan.", "Fev.", "Mar.", "Abr." with a period, and sometimes without. In code, strip punctuation before comparing. Don't do if (month === "fev"), do if (month.toLowerCase().replace(".", "") === "fev"). Brazilian vs. European Portuguese differences are rare for months but not zero. The month names are the same, but the order of day-month-year in display formats differs. Brazil tends toward dd/mm/yyyy while Portugal also uses dd-mm-yyyy in many official contexts. This doesn't affect the names, but it affects parsing. If you're accepting user input, validate the format before feeding it to a date parser.

A Practical Script for Mapping and Validating Portuguese Months

Here's something I use when I need to validate that a given string is a legitimate Portuguese month name or abbreviation. It's not fancy, but it catches the edge cases I described above. This handles the dotted abbreviation issue, the reverse lookup from abbreviation to full name, and the leap year check for February. It's not a full i18n solution, but it's enough for most validation use cases. For actual date parsing in production, use Intl.DateTimeFormat or a library like dayjs with the Portuguese locale plugin. There are scenarios where this approach doesn't help. If you're dealing with historical dates before the Gregorian calendar was adopted in Portuguese-speaking territories (1582 in Portugal, 1942 in Brazil for some official purposes), month numbering and names don't align with the modern system. Also, if your input comes from OCR or scanned documents, "fevereiro" might be recognized as "ferviero" or "feverei-ro" depending on the font and scan quality. In those cases, fuzzy matching or a manual review step is necessary. No amount of locale configuration fixes bad input data.

If you need to process large batches of Portuguese-dated documents, consider using a dedicated OCR engine with Portuguese language packs rather than trying to fix the results in post-processing. The cost of bad recognition far exceeds the cost of proper tooling from the start.