phillippelevidad/guardjs

Guard clauses to easily validate arguments

👨‍💻 About Me:

15 years as Software Engineer and Solutions Architect, I also have a strong experience in Leadership, Product Development and Project Management. Interested in: software architecture and development, excelent communication, people, personal development, playing guitar and travelling :)

---

🛠️ Languages and Tools:

---

🔥 My Stats:

---

✍️ Blog Posts:

• Generative AI and the Age of Summaries
• JavaScript delete: How to Remove Properties from Objects
• Node.js Streams for Efficient Data Processing At Scale
• Advanced Node.js Hacks: Boost Your Development Skillset
• Mastering JavaScript unit tests with the RPG Combat Kata - Iteration Three

guardjs's Issues

Edge case in isoDateTime (February 30th)

Hi,

not using guardjs (yet, perhaps, historically using Joi within the project) but found a possible issue while writing my own guards, validating isoDateTime strings.

add ["2022-02-30T00:00:00.000Z", THROW], to "isoDateTime" cases in Guard.spec.ts

run npm test

Expected result: ✔️ isoDateTime
Actual result: ❌ isoDateTime

---

Why:

new Date('2022-02-30T00:00:00.000Z').toISOString()
// '2022-03-02T00:00:00.000Z'

Perhaps another peculiarity of Javascript's Date(), my PostgreSQL agrees with me, and I'm pretty sure other DBs would as well, February 30th 2022 is not a valid date, hence that should not be a valid ISO string.

select date_part('day', '2022-02-30T00:00:00.000Z'::timestamp);
-- Query 1: ERROR:  date/time field value out of range: "2022-02-30T00:00:00.000Z" ...

whereas

select date_part('day', '2022-02-28T00:00:00.000Z'::timestamp);
-- 28

Since I'm already using moment.js in the project as well, I went the route of using that.

moment('2022-02-30T00:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSSZ').isValid()
// false

However, since you support other tz offsets than just Zulu, the solution would not be as trivial as using return !isNaN(date.getTime()) && date.toISOString() === val;

Cheers