[kronolith] Blank Kronolith page

[Dan Wilson]

: > OK... so I finally decided to give up on mcal and go with sql as well...
: > but
: > I'm running PostgreSQL instead of MySQL and I get this error:
: >
: > ERROR: parser: parse error at or near "{"
: >
: > Of course, that's just part of the error...   it's not liking the time
: > stamp
: > syntax used... here's the full sql statement that it doesn't like:
: >
: > SELECT DISTINCT e.event_id, e.event_recurType
: > FROM kronolith_events e
: > WHERE
: >   e.calendar_id = 'dan@acucore.com'
: >   AND ((e.event_start < {ts '2001-11-18 00:00:00.000'} AND e.event_end >
: >
: > {ts '2001-11-17 00:00:00.000'}) OR (e.event_recurEnddate >= {ts
: > '2001-11-17
: > 00:00:00.000'} AND e.event_start <= {ts '2001-11-18 00:00:00.000'} AND
: > e.event_recurType != 0))
: >
: > Postgres' timestamps use different syntax, and I am too unfamiliar with
: > PEAR to
: > know how to fix it and keep it compatible with other db's.
:
: I know Chuck worked hard to find a syntax as compatible as possible, so if
: anyone knows a better one...
:
: Jan.

Postgres could handle this without anything around the timestamp string.
Just '2001-11-18 00:00:00.000' would work great.  I also tested this with
MySQL, and it accepted the query, but I don't know if the calculations would
be correct.  I'm assuming that the {ts } syntax is the way to cast text to a
timestamp for MySQL?  In Postgres, usually the typecasting is done
automatically, but in the event that it requires a explicit cast, the syntax
would be '2001-11-18 00:00:00.000'::timestamp.

Could someone test to see if we can strip out the {ts ...} syntax and the
calculations still work for mysql?

I also had to change the create table statement in kronolith.sql.  The
default of 0's on the timestamp doesn't work for postgres.  It requires a
valid date.  I changed it to "now()" which is the time of record insertion.

-Dan