I've been working on a TimeSeries class, and in the process have had some success in fleshing out the nature of this (thinobject) system. It appears to work, and I'm hopeful that it will continue to do so, but there's a long way yet to go.
For TimeSeries I've defined two methods, store and get (well, I also wrote a new method to do one simple task).
TimeSeries.store accepts text from the command line or else on standard input, and stores it in a file, with a timestamp. If the "message" (or "datum") is too long, or has multiple lines, it is stored as a "chunk" in a file under the "_/" directory, and the filename is entered in the main timeseries file for the entry.
The max width of a message can be set; I have the default now at 79 characters (for some reason), but am thinking of either setting the default to 0 (no limit), or something much larger.
There's an option to map newlines in the message to return characters, so that multiline messages can be stored on a single line. This is off by default.
The timestamps are recorded as seconds into the year, in universal time (UT or UTC). A timeseries file will not span a year. The filename includes the year and the first and last entry timestamps.
A TimeSeries object could contain several of these files, which I've called either "index" or "control" files, in addition to "timeseries" files.
Work remains to support specifying the timestamp to the store method, but that's a key feature I'll be needing fairly soon. Currently it applies the current time to incoming messages.
The TimeSeries.get method currently has a couple of forms so far,
including "get last N" and "get 2005 131 12:30 to 2005 132", with variations. A lot more work remains to support decent queries, but that will come as it gets put to use.
The local timezone can be specified in the "+/-HHMM" form which is standard to many internet protocols. This defaults to -0900, since that's where I am. I don't recall if the store method has any use for the timezone value, but the get method uses it for something.
I've tried to avoid relying on daylight savings time in order to keep things simple; however, input and output would probably most reasonably be handled using whatever local time is familiar to the users. More needs to be worked out here, but I think the basic idea of storing using UTC and converting to local time using the numeric timezone is sound -- well, at least the UTC anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been working on a TimeSeries class, and in the process have had some success in fleshing out the nature of this (thinobject) system. It appears to work, and I'm hopeful that it will continue to do so, but there's a long way yet to go.
For TimeSeries I've defined two methods, store and get (well, I also wrote a new method to do one simple task).
TimeSeries.store accepts text from the command line or else on standard input, and stores it in a file, with a timestamp. If the "message" (or "datum") is too long, or has multiple lines, it is stored as a "chunk" in a file under the "_/" directory, and the filename is entered in the main timeseries file for the entry.
The max width of a message can be set; I have the default now at 79 characters (for some reason), but am thinking of either setting the default to 0 (no limit), or something much larger.
There's an option to map newlines in the message to return characters, so that multiline messages can be stored on a single line. This is off by default.
The timestamps are recorded as seconds into the year, in universal time (UT or UTC). A timeseries file will not span a year. The filename includes the year and the first and last entry timestamps.
A TimeSeries object could contain several of these files, which I've called either "index" or "control" files, in addition to "timeseries" files.
Work remains to support specifying the timestamp to the store method, but that's a key feature I'll be needing fairly soon. Currently it applies the current time to incoming messages.
The TimeSeries.get method currently has a couple of forms so far,
including "get last N" and "get 2005 131 12:30 to 2005 132", with variations. A lot more work remains to support decent queries, but that will come as it gets put to use.
The local timezone can be specified in the "+/-HHMM" form which is standard to many internet protocols. This defaults to -0900, since that's where I am. I don't recall if the store method has any use for the timezone value, but the get method uses it for something.
I've tried to avoid relying on daylight savings time in order to keep things simple; however, input and output would probably most reasonably be handled using whatever local time is familiar to the users. More needs to be worked out here, but I think the basic idea of storing using UTC and converting to local time using the numeric timezone is sound -- well, at least the UTC anyway.