Comment by nl | Hacker News Reader

Comment by nl | Hacker News Reader

I have no idea what the author is proposing, but I'm just posting to point out that it isn't the unix timestamp that is broken: it's dates in general.

There is simply no algorithm that accounts for their behaviour all the time. The best you can do is have one that works most of the time, and then have a table of exceptions (which has to be locale based).

For example, what date is 15330 days after February 30(!) 1712 in Sweden?[1]

In November 1699, Sweden decided that, rather than adopting the Gregorian calendar outright, it would gradually approach it over a 40-year period. The plan was to skip all leap days in the period 1700 to 1740.

Great.. except:

In accordance with the plan, February 29 was omitted in 1700, but due to the Great Northern War no further reductions were made in the following years.

Oops. Oh well:

In January 1711, King Charles XII declared that Sweden would abandon the calendar, which was not in use by any other nation and had not achieved its objective, in favour of a return to the older Julian calendar. An extra day was added to February in the leap year of 1712, thus giving it a unique 30-day length

But the Julian calendar sucks[2], so:

In 1753, one year later than England and its colonies, Sweden introduced the Gregorian calendar, whereby the leap of 11 days was accomplished in one step, with February 17 being followed by March 1

Once you start doing date work you'll find these crazy cases all the time. Try and tell me today's date on Mount Athos...

[1] https://en.wikipedia.org/wiki/Swedish_calendar#Solar_calenda...

[2] https://en.wikipedia.org/wiki/Julian_calendar

[3] https://en.wikipedia.org/wiki/Mount_Athos#Date_and_time_reck...

His main beef seems to be that time isn't as simple as i++ and he really wish it were. But that's a lot to do with the fact that time is based on the spin and orbit of Earth around the sun.

I think, that he's seriously suggesting that we find a unit of time that can be guaranteed to just increment and not be subject to leap stuff or calendar adjustments and can go forward and backwards in time as simple increments and decrements.

A de-coupling between the time counter and our perception of time as a human concept.

Maybe use the concept of a second, but not in relation to our calendar. So instead of being "seconds since 1970" it's just "seconds".

I guess the idea being that you'd have a guaranteed increment only counter for seconds that have passed, but without coupling that to an actual calendar.

I'd probably ask what the problem was that created this thought, maybe there's an answer to that instead.

> I'd probably ask what the problem was that created this thought, maybe there's an answer to that instead.

OP here. That article is old and I really wish it wasn't on the front page. If I remember correctly, at the time this was written, there were some pretty big outages and failures that originated from apps assuming time was pretty much a linear monotonic value. So the motivation to write this was not only for myself, but to attempt and find a better solution for timestamps as needed by many apps.

There is no technical reason for the timestamp to jump around, and to convert to and from "human" time we already need libraries (especially if we're looking at points in the past or the future), so the argument that system timestamps MUST map to actual time of day is somewhat moot. As it is, the Unix timestamp attempts to be somewhat in the middle, in the end satisfying neither computer nor human requirements. So the idea was to separate those two timing formats completely.

a linear monotonous value

I think you mean "monotonic". Though lots of non-geeks would probably say that "monotonous" applies too. :-)

You're right. Corrected.

This exists, though it's rare to see any software that uses it. DJB's daemontools do, somewhat unsurprisingly.

It's called TAI, International Atomic Time [0], and it's effectively just UTC minus the leap seconds. It's (close to) the actual time being measured by CPUs all about and it's a pain in the ass to convert to and from it due to leap seconds and such, but if you want to just make time somebody else's problem entirely then using TAI will keep you accurate at least.

[0] http://en.wikipedia.org/wiki/International_Atomic_Time

Maybe use the concept of a second, but not in relation to our calendar. So instead of being "seconds since 1970" it's just "seconds".

Any counter you create will have a zero-point somewhere. 00:00 Jan 1 1970 isn't a point in time that moves around, same as any other zero point you elect to have.

I think, that he's seriously suggesting that we find a unit of time that can be guaranteed to just increment and not be subject to leap stuff or calendar adjustments and can go forward and backwards in time as simple increments and decrements.

I have sympathy for this view. Back when I was doing time & date stuff I worked out a decimal calendar as a thought experiment. If you are happy to drop the idea that a "day" has to align with a period of daylight, and/or the "year" has anything to do with seasons then it's pretty easy...

Or just drop the idea of "day"/"year" being a fixed, constant integer number of seconds.

What you are describing is not usually a problem in practice because:

1. Precise timekeeping for dates over 100 years old is not usually required (though perhaps you work in an area that is an exception?)

2. UNIX timestamps are independent of timezones and can be easily mapped to and from local time by standard, well-tested libraries. The Olson database maintains tables of local time zone information for modern time zones: http://en.wikipedia.org/wiki/Tz_database

Here is some discussion of Mount Athos, not sure if this was ever implemented or not though: http://comments.gmane.org/gmane.comp.time.tz/1610

Precise timekeeping for dates over 100 years old is not usually required

Agreed.

though perhaps you work in an area that is an exception?

Thankfully, no. These days I rarely have to deal with dates at all. I still have the scars though..

I find the anomalies extremely interesting for their own sake.

They aren't entirely gone in the modern world, either. Mount Athos is one of the weirder ones, but Ethiopia still uses a calendar similar to the Julian calendar[1].

More practically, though I suspect that in almost all places with non-conventional calendars you can probably use a normal Gregorian calendar too and people will convert for themselves.

[1] https://en.wikipedia.org/wiki/Ethiopian_calendar

Really, if he's advocating doing away with the unix timestamp, I think he still doesn't understand the issue well enough. The unix timestamp (specifically the timestamp from GMT, not your specific time zone offset) is exactly what you want for counting time. A monotonically incrementing integer to them build all the other complex representations from. UTC is great, but it's crap for keeping track of absolute time[1].

As you've pointed out, the problem comes from peoples misunderstanding that time durations are not easily discernible without looking up many, many exceptions in many cases. The best we've got is a simple absolute time, and very specific rules for determining what the human recognizable interpretation of that time was at a specific locale at that time.

The solution to this problem is simple; Change the way everybody reads and thinks about time. It's also, IMHO, impossible because simple ain't easy.

1: http://en.wikipedia.org/wiki/Leap_second

Unix timestamps ARE NOT guaranteed to be monotonically increasing. They just tend to do that.

No, but what they represent is. I could have been clearer in saying that the epoch is as good an underlying representation as we're likely to get, and it isn't that bad. That makes the unix timestamp as based on the epoch a pretty good thing, in my book.

The fact that dates in general are so screwed up is a great advantage for UNIX timestamps.

A single moment in time maps to a single UNIX timestamp and back again with almost no complications or exceptions (the only one I'm aware of being leap seconds, which is fairly minor). This makes it a great way to store and manipulate actual time.

It's then complicated, sometimes enormously complicated, to go from this simple representation to what humans would call a "date". But that's unavoidable, and by using something nice and simple like UNIX time in the backend, you ensure that all of the craziness when dealing with weird human systems stays at the front end where it belongs.

It's not always possible, of course. Some systems need to store "dates" in terms of what humans think they are, not actual moments in time. (For example, storing a birthday as UNIX time would be a bad idea.) But whenever you want an actual moment in time, UNIX time is great.

Reply on news.ycombinator.com