SLOPE: A proposal for better time representation | Hacker News Reader

SLOPE: A proposal for better time representation

jonhmchan.com

3 pointsjonhmchan8 comments

The problem is: unless for statistical analysis of strange phenomena (probably only Physics and geological), the representation of time is inherently HUMAN-centered and this is what gives rise to the very OP's stated CONS.

Unless there is a 'year, month, day', the use of this is probably more theoretical than real.

Don't get me wrong: it is OK as a tool for time-series analysis. But then again, it will lose the Seasons very shortly. And then... A Gregorian update will be needed.

OP here. You're right - what I'm proposing is not directly human readable, but I don't think that means the use of SLOPE is delegated for extraordinary or scientific use cases alone. I am certainly thinking about it as a way between different technologies to talk to one another. The ISO representation of time, YYYY-MM-DDTHH:MM:SSZ, is certainly far more human readable than a series of unix timestamps S;L;O;P;E. However, this is where the advantage stops - especially for the developer who has to parse and manipulate the ISO string.

Take incrementing the timestamp by one day, for example. Intuition would direct you to split the ISO string into it's components, increment the DD data, and reconstruct it. However, it's far more complicated than that: months have different numbers of days, and it would require modifying both MM and DD if so (leap years taken into account too). You may need to increment the year as well if DD==12. Something this simple shouldn't be so difficult. Most languages have standard libraries that contain methods to handle these complexities, but it's a nightmare to deal with different protocols for each to do so. With SLOPE, the point in time can be incremented easily without confusion: add 606024 (86400) to the "start."

I'm probably going to make a follow-up post to address this one issue (it's a big one). With some code, I think it becomes more clear.

As for the seasons and Gregorian point...well...

With ISO 8601 [1] there is already a standardized way of representing dates, times and intervals.

This suggestion has at least one major design flaw - you can not represent many common recurrences using seconds. Not every day has 86,400 seconds, not every month has 30 days, not every year has 365 days.

[1] http://en.wikipedia.org/wiki/ISO_8601

I'm certainly aware of ISO 8601 - in fact, what I'm proposing is a more developer-friendly version of it that is conducive to (what should be) standard manipulations on points, intervals, recurrences, and series of recurrences of time.

When it comes to representing time in seconds, in a development setting, the method is surprisingly rigorous. It certainly can't account for certain kinds of recurrence: i.e. the first Monday of each month, account for leap years, etc. However, for most use cases, it's sufficient.

Using seconds is or at least seems convenient for developers but you can not represent many meaningful recurrences. Birthdays? No, because of leap years. A meeting every Monday at the same time? No, because of daylight saving time. Essentially everything beyond »every hour« is broken because one hour is the largest time unit with a fixed length - day, week, month and year do not share this property but are the units most recurrences are based on.

What do you think about Square's cube? https://github.com/square/cube

I like Cube - it's extremely useful for deriving interesting information once you have the "events" that they're talking about (something similar to what I have here).

What I'm trying to do here with SLOPE is something much more basic though. One could certainly represent time as a JSON object, but as I mentioned near the end of the post, it could even be represented as a single string:

> start;length;offset1,offset2...;period;end

With any of the semicolon delimited portions removed in order. So instead of using a typical timestamp in YYYY-MM-DDTHH:MM:SSTZ, you use a SLOPE string instead. It makes it much more easy to compute across all situations irrespective of the platform being used.

OP here - please ask me anything about this. I want to know how this could be improved, what's wrong with it, etc.

Reply on news.ycombinator.com