NYCPHP Meetup

[inforequest]

WARNING: Casual mentions of periodic functions and linear algebar 
enclosed. But the post starts with "free beer"
--------------------------------------------------------------------------------------------------------------------

Free beer on my deck at 8pm tonight. (really ;-)

My wife will tolerate the often-worse-than-public-restroom use until 
about 11pm, so let's set the event details:
Absolute time zero is right now (2:50pm PST)
Start:  8pm PST
End : 11pm PST

Event #2:  For those who can't fly out to the left coast in time, a 
mirror beer gathering on Hans K's deck in NJ starting at 10pm EST tonight.
Start:  10pm EST
End : 2am next day EST

Reduction handled by business logic/app layer:

Event1(Offset of Start)=310 (minutes from absolute zero)
Event1(Duration)=180
Event2(Offset of Start)=7hrs 10 min = 430 min
Event2(Duration)=180

*if* the time base has 10 minute time slices, then evID1 occupies [310:490]
and evID2 occupies [430:610] of the absolute_time_base.

abs_time[130] is associated with  evID1
abs_time[140] is associated with  evID1
abs_time[150] is associated with  evID1
.
.
.
abs_time[430] is associated with  evID1,evID2
abs_time[440] is associated with  evID1,evID2
.
.
.
abs_time[490] is associated with  evID1,evID2
abs_time[500] is associated with  evID2
.
.
.
abs_time[610] evID2
abs_time[620] NULL


Make mine weekly. Luckily, "weekly" is digital except for disturbances 
(like DST). If I assume "disturbances" are processed against the 
time_base locally, then, all I need to do is preset the busy_times as
(7 days = 7 x 24 x 60 = 10080 minutes) so
130+10080=10210
10210+10080=20290
20290+10080=30370 etc

abs_time[10210] evID1
...
abs_time[10210=180] evID1

abs_time[20290] evID1
...
abs_time[20290+180] evID1

abs_time[30370] evID1
...
abs_time[30370+180] evID1


Note the assignment of evID1 because nothing else had changed (same 
venue, beer). If I make one week a wine event, it has to have a new 
eventID (evID3) so it can have new properties. Yes it can 
inherit...that's not the point here.

So by this, I have a time_scale of 10 minute slices assigned to an 
unlimited number of evIDs as scheduled. Let this be the "virtual" 
database, because nobody wants to manage time as a collection of 10 
minute slices ad-infinitum.

Or do we?

The linear algebra that can be used to manage an array of uniform time 
slices like that is very, very fast. An "event" is a function of time 
f(t). A "disturbance" such as daylight savings time is a (usually 
linear) warping of the time base..a set of limits on t for which f(t) is 
to be adjusted by some algorithm. In fact, non-linear warping is fine, 
too  so if for example putamare is introducing some reality-augmenting 
substances to his chyme ("chyme, meet my colorful little sugar-coated 
friend") during the time that overlaps an event, the calendar can 
non-linearly warp time for him so he stays in step with the rest of the 
crowd (provided anyone can characterize putamare....let that stand as an 
assumption for now).

So we don't really need to store an event as a sequence of bits but as 
an periodic function. For most events the event function is completely 
described by a constant (event is ON or OFF) and for one-time events the 
preiodic event is similarly trivial as it is also a constant plus a 
start/duration.

For recurring events that are sensible, the storage is simply a few 
parameters representing a periodic function (square wave...square wave 
with a frequency of oscillation and a start). For really complicated 
recurring events, there is a predictable periodicity if they are based 
on the calendar (and they can therefore be written as functions). That 
covers anything that references days of the week or nth week of the 
month or nth Tuesday of even months during Spring and Fall or even moon 
phases or dates relative to DST even.

Even whacked recurring events can often be referenced to another 
singular definable event and are thus easily represented as functions. 
Completely arbitrary recurring events, are well.... not recurring :-)

So what gets stored (and queried)? Well... seems unlikely we want to do 
linear algebra on a web server for potentially every HTTP request, so we 
need temp tables of "event date". How often must they be regenerated? 
How far out into the future do we need to have handy, or at what cost do 
we ask the smarter server to regenerate them? How often will it be 
updated, and how far into the future?

All application specific...but think of all that a-priori knowledge 
available to the application developer at that point. A doctor may 
schedule 15 minute appointments across 4 rooms 3 months in advance.... A 
hotel may book night long reservations 2 years in advance.  A cruise 
ship may book week long reservations 2 years in advance. When the Doctor 
looks ahead 2 months, pause to regenerate that table set? At first 
looking back is clumsy as it can be huge... but then history won't 
change so those are archives anyway.

Plenty of flexibility and it all belongs to the application developer. 
That's what I see so far...