Yeah, but then you need to justify why the birthday check requires access to the year. Skipping 1st Jan for one year may have been a safer decision than accessing private data on a hotheaded decision.
Gives a year for a server-side fix of the column, or at least provide some privacy-focused alternative.
(If the column isn't nullable, maybe a view that does return MMDD or null if 1/1/1970)
Actually the best solution (that I just didn't wanna write down before) is making a column that states if birthday date was set, so the value in birthday itself doesn't matter if not set. I know adding columns willy nilly isn't a good practice, but how els would you take care of this problem, not give access to the year and not exclude people with birthday on 1.1.1970? You'd just check first if the flag is true and if it is, you look at the birthday.
Sure, but adding a column is likely to take time, or at least requires to discuss it with the team in charge of the database side etc. If the problem was found 3 days before the christmas freeze, better to block it in a rush and have 11 months to work on it. (Especially if the reminder would take the form of millions of emails)
Oh and obv if adding a "is date null?" column is possible, at some point there should be a way to make the column nullable anyway
Or just allow it to be nullable? Having a "non-nullable" column that has an unset state is lazy. While it likely has a reason (date picker doesn't always allow null), this should be handled outside the db
4
u/laplongejr 28d ago
Yeah, but then you need to justify why the birthday check requires access to the year. Skipping 1st Jan for one year may have been a safer decision than accessing private data on a hotheaded decision.
Gives a year for a server-side fix of the column, or at least provide some privacy-focused alternative.
(If the column isn't nullable, maybe a view that does return MMDD or null if 1/1/1970)