Re: Design-stage advice and opinions welcomed
From: Thomas 'PointedEars' Lahn <PointedEars_at_web.de>
Date: Fri, 25 Sep 2015 04:57:36 +0200
Message-ID: <1989121.8MaefjtRha_at_PointedEars.de>
>
> No, I can't. it seems to me to be a excellent and robust way of handling
> this situation. ISTM that what I'm aiming for is not a set-in-stone
> calendar but a way of predicting what will happen, all other things being
> equal. […] Seriously, what's the problem? genuine question, I'm not doing
> a Richard.
Date: Fri, 25 Sep 2015 04:57:36 +0200
Message-ID: <1989121.8MaefjtRha_at_PointedEars.de>
Derek Turner wrote:
> On Thu, 24 Sep 2015 22:58:49 +0200, Thomas 'PointedEars' Lahn wrote:
>> Still, simply storing trivial strings as dates is not a viable approach >> for an event calendar. Can you think of a reason why
>
> No, I can't. it seems to me to be a excellent and robust way of handling
> this situation. ISTM that what I'm aiming for is not a set-in-stone
> calendar but a way of predicting what will happen, all other things being
> equal. […] Seriously, what's the problem? genuine question, I'm not doing
> a Richard.
In addition to what I said in another paragraph: You will have to parse those strings in order to select the algorithm for computing the future dates from the previous one.
It is much better to use language-independent codes for storing data such as “first Tuesday”; for example number=1, weekday=2, repeat=TRUE. From that you can either construct a string for strtotime(), or use another algorithm to arrive at the dates (it is easy to determine the date of the first of a certain weekday in a month even without strtotime()).
-- PointedEars Twitter: _at_PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.Received on Fri Sep 25 2015 - 04:57:36 CEST