4 ms·
There should be no time component to a properly-stored birthdate. One doesn't observe a "January 1 in Australia" birthday on December 31 in New York. Systems
by sk5t 8y ago
There should be no time component to a properly-stored birthdate. One doesn't observe a "January 1 in Australia" birthday on December 31 in New York. Systems that presume a birthday to be other than a year+month+dayofmonth get themselves into the sort of trouble described in this thread. Birthdays well in the past, however, might need more information on the observed calendar/chronology in use in the subject's locale.
OTOH, if you need "instant of birth" then definitely get a time and timezone. Plus, converting to UTC and discarding the timezone observed at the place and political circumstance of birth would likely be a mistake.
- untog 8y agoMy point is that no one "misunderstands" this. Everyone knows a birthday encompasses an entire day. This is a bug, not a misunderstanding.
- sk5t 8y agoI feel you're being pedantic. The misunderstanding is not around the concept of a birthday, yes--it's due to the use of a time-having datetime datatype for this purpose, in UI and/or application server or database layers, the latter of which ought to reject datetimes as nonconforming inputs.