Building a Simple Age Calculation Feature with n8n

Tips & Tricks
1

Hi developers,

I was experimenting with n8n to create a small workflow that can calculate a user’s age based on their date of birth. The workflow takes an input date, processes it through a function node, and then outputs the age in years, months, and days.

For validation and additional testing, I used an external tool: Age & Hijri Date Calculator. It’s useful because it supports both Gregorian (ميلادي) and Hijri (هجري) calendars, which is often required in projects targeting international or Arabic-speaking audiences.

Here’s the simple workflow I tested:

  1. Input node → enter Date of Birth.

  2. Function node → calculate age difference.

  3. Output node → display/send results.

I’m curious:

  • Has anyone implemented a Hijri calendar conversion directly inside n8n?

  • Or is it better to connect with an external API/tool like this for more accurate results?

Looking forward to your suggestions!

Thanks,
Ahmad

1 Like
2

Hi Ahmad,

Great post! Your experiment is a classic example of a deceptively complex problem—date math is always trickier than it seems. Handling multiple calendar systems makes it even more impressive.

To answer your questions:

1. Has anyone implemented a similar date/age calculation workflow?
Yes, absolutely. Calculating age or time differences is a common use case, especially in sectors like healthcare, e-commerce (for age verification), and HR. Your approach using a Function node is the standard and most flexible way to do it in n8n. It allows for precise control over the calculation and output format.

2. Is there a more efficient way to handle Hijri calendar conversion?
This is the challenging part. While n8n’s native $now and date functions are powerful, they are strictly Gregorian.

  • Pure n8n Solution: For a purely internal method, your only option would be to use a Code Node with a robust JavaScript library like hijri-converter or luxon. You would have to add the library via npm and require it in your function. The major downside is that this adds dependency management overhead to your workflow.

  • External API Solution: Using a dedicated, validated external API (like the one you referenced) is often the more reliable and accurate approach. It ensures the complex calendar calculations are handled by a specialized service. You can use the HTTP Request node to call this API and parse the result. While it adds an external dependency, it often results in a more maintainable and accurate workflow.

A Suggested Hybrid Approach for Your Workflow:
You could make your workflow more powerful by giving the user a choice:

  1. Use an IF Node to check if the input date is Hijri or Gregorian.

  2. If Gregorian, proceed with your current Date Function node calculation.

  3. If Hijri, branch out to an HTTP Request node to convert the date using a free API (like https://api.aladhan.com/v1/hToG?date=[DD-MM-YYYY]), then calculate the age from the converted Gregorian date.

This would make your workflow versatile for both calendar systems.

I’d be very interested in seeing a snippet of the code in your Function Node. Would you consider sharing it? I’m sure others in the community would find it incredibly useful.

Thanks for bringing up this interesting topic!

Best,

Neha

3

Thanks NehaArshad

4

Hi Ahmad,

I know this thread is a few months old, but I wanted to jump in because the Hijri calendar conversion question is still very relevant for anyone building localized workflows in 2026.

To answer your first question: Implementing Hijri conversion directly inside a Function (Code) node is definitely the way to go if you want to keep the workflow lightweight. You can use the Intl.DateTimeFormat object in JavaScript (which n8n supports) to handle the islamic-umaq calendar without needing a heavy external library.

However, the tricky part is always the precision of the Hijri date offset. For testing my custom n8n code and ensuring the day-shifts are accurate across different regions, I’ve been using age calculator sa as my source of truth. It’s particularly helpful for double-checking the edge cases where the lunar month might differ by a day in specific calculation engines.

Quick Tip for the Code Node: If you’re using the newer n8n versions, try using this logic in your Code node to get the Hijri year directly:

const date = new Date(item.json.dob);
const hijriDate = new Intl.DateTimeFormat('en-u-ca-islamic-umaq-nu-latn', {
  day: 'numeric',
  month: 'long',
  year: 'numeric'
}).format(date);
return { hijriDate };

Has anyone found a better way to handle the ‘sighting’ variation in Hijri dates within n8n, or are most of you still relying on external validation tools for that?"

1 Like