Hacker News Reader

Comment by Traubenfuchs | Hacker News Reader

I feel like this goes far beyond the core usage of date and datetime values and makes serializing, deserializing and parsing more difficult than it needs to be.

Why would you ever need this bizarre piece of date(time) metadata ((un)certainty) encoded into your date(time) string?

View on HN

Datetimes are frequently uncertain or approximate in many real world contexts, and failing to indicate that is a form of lossy storage. Sometimes that loss is acceptable, and sometimes it is not.

Any date information collected from non-computer processes can have missing or incorrect dates (e.g., doctor's notes, or a historical record saying "1920s"). Despite that, you may need to do comparisons between them. This lets us keep the dates in one field, do the normal logic with complete values, and do some limited logic with incomplete ones. For example:

    # This is true
    Date("192X-XX-XX") >= Date("1920-01-01")
    # This is false
    Date("192X-XX-XX") < Date("1920-01-01")
    # This is unknown
    Date("192X-XX-XX") == Date("1920-01-01")

I don't like splitting dates across multiple fields and writing custom logic. It'd be nicer to have a standard and (eventually) a good library to lean on.

I think there is a problem with the meaning of the '==' sign here. You are using algebraic notation where we are really dealing with ordered sets and their members. So '==' meaning equivalence is not very useful here. 'Date("192X-XX-XX")' denotes the interval [Date("1920-01-01") ... Date("1929-12-31")]. So '<', '>', '==' should best be defined in terms of ordered sets:

  d < I means date d is before any date in I
  d > I means date d is after any date in I
  d == I means date d is included in I

This would make your last equation 'true'.

If instead you rather prefer to leave 'd == I' undefined, I could hardly find it convincing that you assign a truth value to '<='.

I've corrected the first date comparison to be ">=". Thanks for pointing that out.

>'Date("192X-XX-XX")' denotes the interval [Date("1920-01-01") ... Date("1929-12-31")]

The partial date is not the set, but a single date that is in a set. There is notation for sets of dates:

    # Each means a single day in the 1920s
    192X-XX-XX
    [1920-01-01..1929-12-31]
    # A collection of all days in the 1920s
    {1920-01-01..1929-12-31}

The company I work for is in international logistics (Flexport) so as you can imagine, dates and times are quite important. We have standardized internal time definitions that can represent uncertainty, which were the result of much discussion. I was surprised to learn there are ISO standards for time uncertainty, since I don't recall this ever coming up.

This level of uncertainty would, I think, have too much flexibility for lots of normal business code. There is always an inherent tradeoff when writing code for use cases capturing real-world events between perfect fidelity of your model and coding ergonomics. Things about the real world are not known with perfect certainty, but if you can't capture them with discrete types (for example, CAR_STARTED vs. [Probability of CAR_STARTED = 99.9%, Probability of START_SENSOR_MALFUNCTION = 0.1%]), your downstream logic will be a huge mess. It can be cheaper to handle rare issues caused by lack of fidelity with business processes. Our time notion does not have as many degrees of freedom as this standard.

Twice I’ve had to write custom date parsing/handling libraries for employers to handle this sort of thing, most recently to accommodate translation of English language descriptions of health events. “Patient started taking drug in April” e.g., and I needed to provide date calculations against that.

Representing partial information can be important in some use cases, mostly related to historical contexts.

I run into this all the time in genealogy. The date object in Gramps, for example, has to support lots of uncertainty, as well as time spans with uncertainty on either end ("He joined the army in March 1968 (unknown day), and left sometime after 1971 but probably before 1974 when he got a job at ABC Corp.").

Throw in different calendar systems and you can have a mess. It's one of the things that people think is simple, but really isn't.

Reply on news.ycombinator.com