3 ms·

I like the concept but I’ve seen a fair few examples of where the developers and users clearly had differing opinions about which states are invalid! Dates are

by jl6 6y ago

I like the concept but I’ve seen a fair few examples of where the developers and users clearly had differing opinions about which states are invalid! Dates are a rich vein of examples. Some users will happily consider “25th December” to be a date, without any year, because it might be the name of a folder in which they store their Christmas stuff. More seriously, genealogists or historians may want to record “25th December” (again without a year) as the date of a photograph because they can clearly see it was taken on a Christmas, they just don’t know which one. The naive developer would just slap a DateTime type onto the system and feel good about having avoided malformed input.

isbvhodnvemrwvn 6y ago
Also in genealogy: - estimated dates - calculated dates (e.g. someone was 30 in 1870, so he was born in "calculated 1840") - unreadable or unavailable months or days (typically recorded as 1980-00-13) - time ranges with all of the above as boundaries e.g. "after 1760-03-00 and before calculated 1800" - plainly incorrect dates, but that's what the document says (1865-02-30) - no dates (some software tries to enforce putting in some data in for whatever reason) - dates with unknown calendar
- Terr_ 6y ago
  All plausible and scary. It sounds like a recipe for a system where the different qualities of dates are their own entity, and anybody doing a date-search needs to provide some criteria on the degree of specificity or certainty they require. For that matter, someone might want to do a text-based search on dates: "This damaged photo shows 196_-_1, which could be at least 20 different months..."
  - isbvhodnvemrwvn 6y ago
    There's also another dimension to that uncertainty. Dates are typically attributes of events involving one or more people in various roles, and these events are (hopefully) attached to one or more sources. The type of sources you use affects the confidence of various attributes of the event (like dates or participants). In my area of research death records are typically a bad predictor for date and location of birth. When the records were managed by the churches (until after WWII pretty much), priests did not want to pester grieving family for the exact date of birth, so they relied on approximate age. Naturally the subject of the death record would not typically point out errors. On the other hand marriage records required looking at the actual birth records (sometimes mailed across the country), as these contained notes on all marriages of the individual (this was done to ensure monogamy). Is it on the genealogist to consider this confidence when specifying the date of the event, or should the software intervene? Due to complexity, the former is the industry standard. But maybe there are some brave (or stupid) people who will try to take it into account in the future.
    - jl6 6y ago
      I implemented a [private] genealogical data entry system based on the GenTech data model, which has a "surety scheme" entity, designed to capture perceived uncertainty. I also added a "Fuzzy Date", where every date-like value was decomposed into all its constituent components (year, month, day, hour, ...), all optional. It could also capture a range of such fuzzy dates, so it was possible to enter a "date" such as "The first of a month no earlier than 1950 and before June 1990". There was a loooong list of validation constraints to attempt to prevent contradictions being entered, and I think I caught all the cases, but...
deleted 6y ago
[deleted]
kroltan 6y ago
But then you're not dealing with dates at all, just categories which happen to have names that look like dates, no? Like you say, a "folder". But the photo file's metadata will either have a complete DateTime, or none at all, unless there is some sort of camera that is able to know what day of the year it is without knowing the year! Which due to things like leap years is impossible.
- rocqua 6y ago
  > But then you're not dealing with dates at all, just categories which happen to have names that look like dates, no? If you and your client disagree about what constitutes a date, that doesn't mean "your client is wrong" it means "you need better communication. You can't fix this problem by requiring everyone use consistent definitions. Instead the solution is to check assumptions as often as possible.
- IggleSniggle 6y ago
  Importantly, these “date-like” things have important date-semantics. That is, it may be reasonable to expect your software to be able to handle varieties of precision or completeness of date metadata, in which case your date representation may need to be able to interact with DateTime fluidly without actually being one itself, despite it being tempting to remove these possibilities by making incomplete date information unrepresentable.
- will4274 6y ago
  > some sort of camera that is able to know what day of the year it is without knowing the year! Which due to things like leap years is impossible. Just a small note, as we're talking about assumptions, but this is clearly untrue. Consider - for decades, humans wore watches that knew the day of the month, but not the month - you were just expected to turn the day forward on the 1st day of months following non-31 day months. Similarly, we can imagine disposable cameras that ask the user for the current day on first use and simply assume leap years don't exist, and require the user to correct the date for any leap years. You might call this a silly design, but systems often have to interact with external systems that have silly designs. I believe I actually owned a toy PDA (a device for a child, not an adult) that did not have a year back in the 2003 or so.
IggleSniggle 6y ago
This is so obvious now that you’ve said it. I can see so many possibilities. I feel as though my eyes have been opened.
lkitching 6y ago
If you only have a day and month like 25th December you should represent it with a type that contains just that information. Java for example has the MonthDay class (https://docs.oracle.com/javase/8/docs/api/java/time/MonthDay.html https://docs.oracle.com/javase/8/docs/api/java/time/MonthDay...) which can be converted into a local date when the additional information is available. If your users want to refer to that as a date then that should be handled in the UI but should not lead to ambiguity in the internal representation.

by jl6 6y ago

isbvhodnvemrwvn 6y ago

Also in genealogy: - estimated dates - calculated dates (e.g. someone was 30 in 1870, so he was born in "calculated 1840") - unreadable or unavailable months or days (typically recorded as 1980-00-13) - time ranges with all of the above as boundaries e.g. "after 1760-03-00 and before calculated 1800" - plainly incorrect dates, but that's what the document says (1865-02-30) - no dates (some software tries to enforce putting in some data in for whatever reason) - dates with unknown calendar

Terr_ 6y ago
All plausible and scary. It sounds like a recipe for a system where the different qualities of dates are their own entity, and anybody doing a date-search needs to provide some criteria on the degree of specificity or certainty they require. For that matter, someone might want to do a text-based search on dates: "This damaged photo shows 196_-_1, which could be at least 20 different months..."
- isbvhodnvemrwvn 6y ago
  There's also another dimension to that uncertainty. Dates are typically attributes of events involving one or more people in various roles, and these events are (hopefully) attached to one or more sources. The type of sources you use affects the confidence of various attributes of the event (like dates or participants). In my area of research death records are typically a bad predictor for date and location of birth. When the records were managed by the churches (until after WWII pretty much), priests did not want to pester grieving family for the exact date of birth, so they relied on approximate age. Naturally the subject of the death record would not typically point out errors. On the other hand marriage records required looking at the actual birth records (sometimes mailed across the country), as these contained notes on all marriages of the individual (this was done to ensure monogamy). Is it on the genealogist to consider this confidence when specifying the date of the event, or should the software intervene? Due to complexity, the former is the industry standard. But maybe there are some brave (or stupid) people who will try to take it into account in the future.
  - jl6 6y ago
    I implemented a [private] genealogical data entry system based on the GenTech data model, which has a "surety scheme" entity, designed to capture perceived uncertainty. I also added a "Fuzzy Date", where every date-like value was decomposed into all its constituent components (year, month, day, hour, ...), all optional. It could also capture a range of such fuzzy dates, so it was possible to enter a "date" such as "The first of a month no earlier than 1950 and before June 1990". There was a loooong list of validation constraints to attempt to prevent contradictions being entered, and I think I caught all the cases, but...

deleted 6y ago

[deleted]

kroltan 6y ago

But then you're not dealing with dates at all, just categories which happen to have names that look like dates, no? Like you say, a "folder". But the photo file's metadata will either have a complete DateTime, or none at all, unless there is some sort of camera that is able to know what day of the year it is without knowing the year! Which due to things like leap years is impossible.

rocqua 6y ago
> But then you're not dealing with dates at all, just categories which happen to have names that look like dates, no? If you and your client disagree about what constitutes a date, that doesn't mean "your client is wrong" it means "you need better communication. You can't fix this problem by requiring everyone use consistent definitions. Instead the solution is to check assumptions as often as possible.
IggleSniggle 6y ago
Importantly, these “date-like” things have important date-semantics. That is, it may be reasonable to expect your software to be able to handle varieties of precision or completeness of date metadata, in which case your date representation may need to be able to interact with DateTime fluidly without actually being one itself, despite it being tempting to remove these possibilities by making incomplete date information unrepresentable.
will4274 6y ago
> some sort of camera that is able to know what day of the year it is without knowing the year! Which due to things like leap years is impossible. Just a small note, as we're talking about assumptions, but this is clearly untrue. Consider - for decades, humans wore watches that knew the day of the month, but not the month - you were just expected to turn the day forward on the 1st day of months following non-31 day months. Similarly, we can imagine disposable cameras that ask the user for the current day on first use and simply assume leap years don't exist, and require the user to correct the date for any leap years. You might call this a silly design, but systems often have to interact with external systems that have silly designs. I believe I actually owned a toy PDA (a device for a child, not an adult) that did not have a year back in the 2003 or so.

IggleSniggle 6y ago

This is so obvious now that you’ve said it. I can see so many possibilities. I feel as though my eyes have been opened.

lkitching 6y ago

If you only have a day and month like 25th December you should represent it with a type that contains just that information. Java for example has the MonthDay class (https://docs.oracle.com/javase/8/docs/api/java/time/MonthDay.html https://docs.oracle.com/javase/8/docs/api/java/time/MonthDay...) which can be converted into a local date when the additional information is available. If your users want to refer to that as a date then that should be handled in the UI but should not lead to ambiguity in the internal representation.