

SLOPE: A proposal for better time representation - jonhmchan
http://www.jonhmchan.com/thoughts/2013/4/9/slope-a-new-way-to-represent-time

======
pfortuny
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.

~~~
jonhmchan
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 60 _60_ 24 (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...

------
danbruc
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>

~~~
jonhmchan
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.

~~~
danbruc
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.

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

~~~
jonhmchan
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.

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

