4 ms·

SLOPE: A proposal for better time representation

3 points by jonhmchan 13y ago

jonhmchan 13y ago
OP here - please ask me anything about this. I want to know how this could be improved, what's wrong with it, etc.
dbyrd 13y ago
What do you think about Square's cube? https://github.com/square/cube https://github.com/square/cube
- jonhmchan 13y ago
  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.
danbruc 13y ago
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 http://en.wikipedia.org/wiki/ISO_8601
- jonhmchan 13y ago
  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 13y ago
    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.
pfortuny 13y ago
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 13y ago
  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...

3 points by jonhmchan 13y ago

jonhmchan 13y ago

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

dbyrd 13y ago

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

jonhmchan 13y ago
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.

danbruc 13y ago

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 http://en.wikipedia.org/wiki/ISO_8601

jonhmchan 13y ago
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 13y ago
  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.

pfortuny 13y ago

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 13y ago
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...