On Jun 12, 2006, at 7:37 PM, martinrp@alcor.concordia.ca wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
Yeah, I guess that makes sense to avoid symbols. In which case, it probably makes sense to split up the UNIX time_t into two numbers, the first is the date in days, the maximum being 49,710 days, then the time of day in seconds, the maximum being 86,400 seconds, then the number of fractional seconds as a float (eg. 0.023414)
It seems way more logical to me to split it into years and day of year at least. Of course we could work with katuns and tuns like the Maya, it's arguably a more rational system ;). Martin
It seems to me that breaking up the time into each component leads to some very long lists, so this method would be more compact. The parsing of this format could easily be done with Pd core.
A 7-component list is too much for pd?
Not at all. But dealing with 7 component lists means a lot of cord connections, which is not so fun. I just wrote a [stat] object to get info from files. It outputs access-time, modification-time, and status-change-time. That's 18 elements instead of 6, plus there are already 7 other properties output.
Plus I think its a neat breakdown the first element in days is equal to the date, so today is 13312, which is exactly equal to 2006-06-13. Right now, its 39325, which converts perfectly to 10:55:25. Then one more number for microseconds (since Pd can only do up to 6 digits). It seems quite clean to me, considering the limitations.
.hc
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.