5 ms·

I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a

I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning about it as a point or interval in time and people’s birthdays changing when they move timezones.

_mlbt 1y ago
Even better, just make the user input dates using a calendar date picker widget instead of a text field. This gives you full control of the input.
- Tyr42 1y ago
  I've had to click back once per year old I am sometimes. I'd rather just type my birthday.
- mattkrause 1y ago
  I always find that a little annoying: it takes way too many clicks (esp. for a birth year) and then you've got to find the day of the week. I'd hate it less if typing updated the widget.
kccqzy 1y ago
> people’s birthdays changing when they move timezones That's because the developers use datetimes (aka timestamps) to store a single date. Just pick an arbitrary epoch date (such as January 1, 1900 as used by Excel, or my favorite January 1, 1600 since 1600 is a multiple of 400 making leap year calculations even simpler) and store the number of days elapsed since then. The rules involving leap years are much much simpler than rules involving timezones and timezone databases. The translation from/to this representation to a broken-down y/m/d takes only ~50 lines of code anyways. Of course if you don't need to do arithmetic on dates, just store three numbers, year, month, and day.
- happytoexplain 1y ago
  In my humble opinion, this is not good advice unless you demonstrably need it for query performance or something. It is very easy for the logic layer to accidentally mess that up, either in reading or, worse, in writing back. In this case, I'd suggest storing what you mean (the user wasn't born 9,487 days after Jan 1 1970. They were born Dec 23, 1995.) Storing the literal units (and ONLY the relevant units), as the parent has, is robust and logically+semantically correct (they could add a translation layer for UX so the user doesn't have to be particular, but that's beside the point). Whether you use a string or a struct or some date-only type is moot, as long as you're literally storing the year, month, and day, and only those three things. You can ephemerally convert it to your platform's date type if you need to.
- SoftTalker 1y ago
  No, don't do that. Use a date datatype (not date/time). You aren't the first person to ever need to handle dates without times/timezones in a computer program. Use what your database/language/libraries already have to support that.
  - tadfisher 1y ago
    Specifically, a "local date", codified as LocalDate in every date library worth a damn, except for Javascript which chose "PlainDate" just to be different.
  - PaulHoule 1y ago
    Well, for hardcore chronology Julian dates are what you do. https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day which are the moral equivalent of Unix timestamps with a different offset and multiplier. These work OK for human history but will break if you go far enough into the past or the future because uncertainty in the earth's rotation adds up over time. If you don't care about timezones timezones may still care about you, if you want to minimize trouble it makes sense to properly use timezone-aware Zulu (GMT) dates for everything if you can. In certain cases you might be doing data analysis or building an operational database for throttling access to an API or something and you know there are 16-bits worth of days, hours, 5-minute periods or something it can make sense to work relative to your own epoch.
8organicbits 1y ago
> in the format 02/18/1993 Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that it's the latter, but that convention isn't universal. I'd recommend YYYY/MM/DD as a less ambiguous format, but I don't have a perfect answer.
- jack_pp 1y ago
  Pretty sure they force the user into that format so that shouldn't be an issue
- kriops 1y ago
  Furthermore, require dashes over slashes to signal that you are expecting ISO-8601 compatible dates, i.e., YYYY-MM-DD. Most users does not know the standard even exists, but it serves as an affordance that it is different from dd/mm/yyyy, etc.
  - PaulHoule 1y ago
    Those ISO-8601 dates are great for date processing with primitive tools such as GNU sort or awk since they sort lexically, at least if you're not comparing dates in different time zones.
    - titzer 1y ago
      ISO 8601 is the way.
      - cyanydeez 1y ago
        alas, the user doesnt know the way...
        PaulHoule 1y ago
        That part is easy. Use a date picker of some kind https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... or a text field with some code that converts vernacular dates to a structured format. I don't think users are going to be too weirded out at seeing "1997-04-15" and will probably learn to use that natively. The hard part is that a lot of devs aren't aware that there's a standard and that standard is superior to the alternatives.
PaulHoule 1y ago
I guess in your case you're never doing date arithmetic or greater than or less than, but only doing equality testing, right? That is, it's part of a composite key. I faced a similar problem with a form where people were supposed to submit a date and probably not aware of what timezone was involved. I figured that so long as they selected "02/28/1993" and people always saw "02/28/1993" that was correct and if they ever saw it differently it was wrong. So I used non-TZ aware dates throughout the whole system.
kaoD 1y ago
I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). Temporal has other cool types, each with distinct semantics: - Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid across the world for any timezone or calendar system. This is what we usually use "Unix UTC timestamps" for. - ZonedDateTime: like an Instant but associated with a particular calendar and location. Think an Instant but rendered "real" into a calendar system and timezone so the user can see a meaningful time for them. - PlainDate: already discussed. Think e.g. birthdates. - PlainTime: think "run task every day at 6:30pm". - PlainDateTime: like an Instant but associated with a calendar system, but no timezone. Think e.g. what a user would insert in a datetime picker, where the timezone is implied instead of explicitly selected. - PlainYearMonth: think e.g. "we'll run our reports during October 2025". - PlainMonthDay: think e.g. "my birthday is June 13". - Duration: think e.g. "the task ran for 3hrs 30min". Also see its important concepts[2]. [0] https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/ [1] https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate [2] https://tc39.es/proposal-temporal/docs/timezone.html https://tc39.es/proposal-temporal/docs/timezone.html
- keeganpoppen 1y ago
  yeah, it was a long (and painful) time coming, but i think the temporal api finally basically nailed it. you know a library is good when you learn something about how to think about the problem just from how the code/api is structured.
  - benreesman 1y ago
    Relatedly, std::chrono isnt exactly a beauty, but it did get people thinking about time points and durations and clocks and which operations are valid ways to move among them. Stuff like this is good.
- Terr_ 1y ago
  I hope that as time goes on software design get better about modeling things that are guesses, conjecture, etc. rather than Absolute Facts. As-is, we assume lots of things are facts and we just hope it's true enough to avoid problems. (Starting with the business requirements. :p )
dragonwriter 1y ago
What environment are you in where you have to work with birthdates, you have timezone aware dates, times, and intervals, but you don't have a naive/plain/local date type that already exists forcing you to use strings in place of date-without-timezone? You seem to have a reasonably expedient solution for that problem, but it is surprising to have the combination of things you have to have and things you have to be missing to have that problem in the first place.
- happytoexplain 1y ago
  They may have something that's just not as easy to work with as strings. E.g. in Swift, you have DateComponents, but that's too dynamic (and Date is sometimes referred to as naive, but that's a misunderstanding, since they are timestamps, not date+time).
- QuadmasterXLII 1y ago
  Javascript/swift/kotlin frontend, python backend, mysql server. The problem wasn’t that I had access to zero (presumably) well implemented time abstractions with all the bells and whistles, it was that I had five well implemented native time abstractions.
BurningFrog 1y ago
Normal/"legal" dates are not timestamps or related to timezones, and this fact will eternally be rediscovered as long as humans write software.
shadowgovt 1y ago
IIUC why medical cares at all, this is really insightful. Because as far as I'm aware, the medical industry basically uses birthdate as a key; it helps to (a) tell two patients with other primary keys (like name or address) apart and (b) do a quick mental-acuity check on the patient by just having them regurgitate the value and doing a human-brain string= on it.
- 1718627440 1y ago
  The dose varies per age, but this isn't that exact.
legulere 1y ago
If you store it just as a string it means that you cannot do anything useful with it like age-dependent logic or you just pass on parsing logic to users of the field. FHIR in my opinion has a pretty good system for dates (including birthdates): YYYY, YYYY-MM, or YYYY-MM-DD. (Not knowing your exact birthday is common for some countries). https://build.fhir.org/datatypes.html#date https://build.fhir.org/datatypes.html#date

_mlbt 1y ago

Even better, just make the user input dates using a calendar date picker widget instead of a text field. This gives you full control of the input.

Tyr42 1y ago
I've had to click back once per year old I am sometimes. I'd rather just type my birthday.
mattkrause 1y ago
I always find that a little annoying: it takes way too many clicks (esp. for a birth year) and then you've got to find the day of the week. I'd hate it less if typing updated the widget.

kccqzy 1y ago

> people’s birthdays changing when they move timezones That's because the developers use datetimes (aka timestamps) to store a single date. Just pick an arbitrary epoch date (such as January 1, 1900 as used by Excel, or my favorite January 1, 1600 since 1600 is a multiple of 400 making leap year calculations even simpler) and store the number of days elapsed since then. The rules involving leap years are much much simpler than rules involving timezones and timezone databases. The translation from/to this representation to a broken-down y/m/d takes only ~50 lines of code anyways. Of course if you don't need to do arithmetic on dates, just store three numbers, year, month, and day.

happytoexplain 1y ago
In my humble opinion, this is not good advice unless you demonstrably need it for query performance or something. It is very easy for the logic layer to accidentally mess that up, either in reading or, worse, in writing back. In this case, I'd suggest storing what you mean (the user wasn't born 9,487 days after Jan 1 1970. They were born Dec 23, 1995.) Storing the literal units (and ONLY the relevant units), as the parent has, is robust and logically+semantically correct (they could add a translation layer for UX so the user doesn't have to be particular, but that's beside the point). Whether you use a string or a struct or some date-only type is moot, as long as you're literally storing the year, month, and day, and only those three things. You can ephemerally convert it to your platform's date type if you need to.
SoftTalker 1y ago
No, don't do that. Use a date datatype (not date/time). You aren't the first person to ever need to handle dates without times/timezones in a computer program. Use what your database/language/libraries already have to support that.
- tadfisher 1y ago
  Specifically, a "local date", codified as LocalDate in every date library worth a damn, except for Javascript which chose "PlainDate" just to be different.
- PaulHoule 1y ago
  Well, for hardcore chronology Julian dates are what you do. https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day which are the moral equivalent of Unix timestamps with a different offset and multiplier. These work OK for human history but will break if you go far enough into the past or the future because uncertainty in the earth's rotation adds up over time. If you don't care about timezones timezones may still care about you, if you want to minimize trouble it makes sense to properly use timezone-aware Zulu (GMT) dates for everything if you can. In certain cases you might be doing data analysis or building an operational database for throttling access to an API or something and you know there are 16-bits worth of days, hours, 5-minute periods or something it can make sense to work relative to your own epoch.

8organicbits 1y ago

> in the format 02/18/1993 Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that it's the latter, but that convention isn't universal. I'd recommend YYYY/MM/DD as a less ambiguous format, but I don't have a perfect answer.

jack_pp 1y ago
Pretty sure they force the user into that format so that shouldn't be an issue
kriops 1y ago
Furthermore, require dashes over slashes to signal that you are expecting ISO-8601 compatible dates, i.e., YYYY-MM-DD. Most users does not know the standard even exists, but it serves as an affordance that it is different from dd/mm/yyyy, etc.
- PaulHoule 1y ago
  Those ISO-8601 dates are great for date processing with primitive tools such as GNU sort or awk since they sort lexically, at least if you're not comparing dates in different time zones.
  - titzer 1y ago
    ISO 8601 is the way.
    - cyanydeez 1y ago
      alas, the user doesnt know the way...
      - PaulHoule 1y ago
        That part is easy. Use a date picker of some kind https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... or a text field with some code that converts vernacular dates to a structured format. I don't think users are going to be too weirded out at seeing "1997-04-15" and will probably learn to use that natively. The hard part is that a lot of devs aren't aware that there's a standard and that standard is superior to the alternatives.

PaulHoule 1y ago

I guess in your case you're never doing date arithmetic or greater than or less than, but only doing equality testing, right? That is, it's part of a composite key. I faced a similar problem with a form where people were supposed to submit a date and probably not aware of what timezone was involved. I figured that so long as they selected "02/28/1993" and people always saw "02/28/1993" that was correct and if they ever saw it differently it was wrong. So I used non-TZ aware dates throughout the whole system.

kaoD 1y ago

I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). Temporal has other cool types, each with distinct semantics: - Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid across the world for any timezone or calendar system. This is what we usually use "Unix UTC timestamps" for. - ZonedDateTime: like an Instant but associated with a particular calendar and location. Think an Instant but rendered "real" into a calendar system and timezone so the user can see a meaningful time for them. - PlainDate: already discussed. Think e.g. birthdates. - PlainTime: think "run task every day at 6:30pm". - PlainDateTime: like an Instant but associated with a calendar system, but no timezone. Think e.g. what a user would insert in a datetime picker, where the timezone is implied instead of explicitly selected. - PlainYearMonth: think e.g. "we'll run our reports during October 2025". - PlainMonthDay: think e.g. "my birthday is June 13". - Duration: think e.g. "the task ran for 3hrs 30min". Also see its important concepts[2]. [0] https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/ [1] https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate https://tc39.es/proposal-temporal/docs/#Temporal-PlainDate [2] https://tc39.es/proposal-temporal/docs/timezone.html https://tc39.es/proposal-temporal/docs/timezone.html

keeganpoppen 1y ago
yeah, it was a long (and painful) time coming, but i think the temporal api finally basically nailed it. you know a library is good when you learn something about how to think about the problem just from how the code/api is structured.
- benreesman 1y ago
  Relatedly, std::chrono isnt exactly a beauty, but it did get people thinking about time points and durations and clocks and which operations are valid ways to move among them. Stuff like this is good.
Terr_ 1y ago
I hope that as time goes on software design get better about modeling things that are guesses, conjecture, etc. rather than Absolute Facts. As-is, we assume lots of things are facts and we just hope it's true enough to avoid problems. (Starting with the business requirements. :p )

dragonwriter 1y ago

What environment are you in where you have to work with birthdates, you have timezone aware dates, times, and intervals, but you don't have a naive/plain/local date type that already exists forcing you to use strings in place of date-without-timezone? You seem to have a reasonably expedient solution for that problem, but it is surprising to have the combination of things you have to have and things you have to be missing to have that problem in the first place.

happytoexplain 1y ago
They may have something that's just not as easy to work with as strings. E.g. in Swift, you have DateComponents, but that's too dynamic (and Date is sometimes referred to as naive, but that's a misunderstanding, since they are timestamps, not date+time).
QuadmasterXLII 1y ago
Javascript/swift/kotlin frontend, python backend, mysql server. The problem wasn’t that I had access to zero (presumably) well implemented time abstractions with all the bells and whistles, it was that I had five well implemented native time abstractions.

BurningFrog 1y ago

Normal/"legal" dates are not timestamps or related to timezones, and this fact will eternally be rediscovered as long as humans write software.

shadowgovt 1y ago

IIUC why medical cares at all, this is really insightful. Because as far as I'm aware, the medical industry basically uses birthdate as a key; it helps to (a) tell two patients with other primary keys (like name or address) apart and (b) do a quick mental-acuity check on the patient by just having them regurgitate the value and doing a human-brain string= on it.

1718627440 1y ago
The dose varies per age, but this isn't that exact.

legulere 1y ago

If you store it just as a string it means that you cannot do anything useful with it like age-dependent logic or you just pass on parsing logic to users of the field. FHIR in my opinion has a pretty good system for dates (including birthdates): YYYY, YYYY-MM, or YYYY-MM-DD. (Not knowing your exact birthday is common for some countries). https://build.fhir.org/datatypes.html#date https://build.fhir.org/datatypes.html#date