Hacker News Reader

The way to deal with dates is not by having separate fields. It's by having a single value represent the time (in Linux it's time_t). Every other format gets translated to time_t, all processing is done with time_t, and then the time_t gets translated to the desired output format.

Any other scheme is doomed to working 99% of the time, and that last 1% will be impossible to fix.

View on HN

> It's by having a single value represent the time

I have limited experience dealing with human originated time references, but from my encounters, the various idiosyncratic forms of date storage often seem to arise out of an aversion to commit to well defined intervals of uncertainty / margins of error. Coercing people of limited mental bandwidth or interest beyond immediate gratification to go through the pain of constricting their mental models to time_t levels of precision seems to basically be a non-starter.

This is of course exactly what I've been meaning to say here. We want more specific datatypes (e.g. a true date(time) ADT) with better functionality (say interval computation) and constraint checking (AKA domains, such as 'let n be an even, positive integer gt zero').

Reply on news.ycombinator.com