[PD-dev] common date format for Pd

Hans-Christoph Steiner hans at eds.org
Tue Jun 13 22:49:12 CEST 2006


On Jun 13, 2006, at 11:51 AM, martinrp at alcor.concordia.ca wrote:

> Quoting Hans-Christoph Steiner <hans at eds.org>:
>
>>
>> On Jun 12, 2006, at 7:37 PM, martinrp at alcor.concordia.ca wrote:
>>
>>> Quoting Hans-Christoph Steiner <hans at 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.
>
> With that method you need another object to convert from raw days  
> to the actual
> date. I'm not sure you really save on patch cords.
> Also you need to specify what date day zero refers to. What about  
> using the
> Julian date, it's more of an international standard than Unix time?
>
> Martin

I figure mostly people will be using dates to compare things.  Either  
way, you'll want to have some objects to do things with dates since  
neither format allows straight comparison.  But it wouldn't be too  
hard to make objects in Pd that support lists of 1-3 for the date/day/ 
microseconds or lists of 5-7 for year/month/day/hour/minute/second/ 
microsecond format.

Using a common standard like UNIX time or Julian date would be much  
preferred, but we are limited to 6 digits, so neither one of them  
works until Pd is all 64-bit.

.hc

------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war  
on terrorism.        - retired U.S. Army general, William Odom






More information about the Pd-dev mailing list