smd_calendar: complete schedule / event / calendar / diary

rsilletti · 2010-02-27 03:18:21

Would this line of code cause a problem, duplicating the usage of tz_offset: (code lines are 1087 & 1097) in view of the fact the tz_offset is used inside safe_strftime?

	$this->dayNames[] = ucfirst(safe_strftime($fmt, 86400*$i - tz_offset(), $this->gmt, $this->lang ));

PascalL · 2010-02-27 19:17:33

Bloke, I’m very proud today, I have found where the bug hides!!! :D

at line 1582 you have this line of code:

$tm = strtotime($val);

but, $val contains a date like this: 24 avril 2010
and strtotime only understands english formats!

As a matter of fact, when I change admin language to english, the problem disappears.
Now Iet’s find the place where $val is defined.

PascalL · 2010-02-27 20:19:17

at line 1577, I’ve changed

$xtras = array_merge($xtras, smd_expand_daterange($val, '', '', "%d %B %Y"));

with

$xtras = array_merge($xtras, smd_expand_daterange($val, '', '', "%F"));

and it seems to work for now

Bloke · 2010-02-27 21:48:40

PascalL wrote:

$val contains a date like this: 24 avril 2010 and strtotime only understands english formats!

Yes. The PHP manual claims:

Parse about any English textual datetime description into a Unix timestamp

So any other language will stop it working. I can now see why it’s falling over — thanks for the hint. You should be able to alter that line to:

$xtras = array_merge($xtras, smd_expand_daterange($val, '', '', "%d %m %Y"));

to fix the issue. I stupidly used %B which returns the locale-dependent month name; $m is more robust as it returns the month number. However, this will possibly cause other problems, for example it might create a date like 05 06 2010 and strtotime might choose May 6th instead of 5th June. So I’ll have to come up with a non-ambiguous, numeric-only date format to pass to strtotime. Suggestions welcome from anyone :-)

rsilletti

Thanks for spotting that one. That’s not the only place I’ve been retarded and applied stuff twice :-\ I’ve got to go through the code with a fine tooth comb and check that I consistently apply safe_* functions only when I’m dealing with stuff going in/out of the database. Any custom field values or other calculated arguments need to use the vanilla PHP functions. I’ve also got to check that I’m using tz_offset() consistently. For example, when creating dates from a month I use PHP’s mktime() quite a bit. Chances are that’ll have the server offset applied to it, so I’ll have to subtract (or add?) tz_offset() every time I generate a timestamp to correct it. But if I then use safe_* functions on that value at any time later, I probably shouldn’t use a manual tz_offset() adjustment at creation time or I’ll get a double offset applied. Argggghhh!

So maybe I just shouldn’t bother with tz_offset() at all and keep everything local until such time as I post stuff to the database or read values back from it? Gonna require some experimentation. I wonder if I can run XAMPP on a local box and set PHP/Apache’s own timezone to something different from the host machine to simulate a server environment at a different location to the browser / TXP install. Hmmmmm. Any ideas?

PascalL · 2010-02-27 22:32:16

So maybe I just shouldn’t bother with tz_offset() at all and keep everything local until such time as I post stuff to the database or read values back from it? Gonna require some experimentation.

My first thought is that maybe you should not bother with timezone too much. When someone posts a date for an event, he naturally gives start hour in his local time. To go further, imagine this: I’m in CET zone, but want to give start time of an event happening in London. I won’t use CET time for this, it wouldn’t make any sense! I’ll use the time which applies where the event takes place! So, the use of raw dates and hours, untouched, from user input seems correct.
But, on a second thought, it seems I missed one use case: what if some events happen on the internet, and gathers people from different timezones at the same time?
It seems there are incompatible use cases, then. Maybe some choices have to be made, or option inside the plugin. I see that a “gmt” attribute is on its way.

Well, I hope not to add more trouble to this already difficult subject. If only earth was flat !

Bloke · 2010-02-27 23:31:47

PascalL wrote:

My first thought is that maybe you should not bother with timezone too much.

I wish it was so simple! Let’s make the Internet Beat the standard unit of time the world over and get rid of DST!

When someone posts a date for an event, he naturally gives start hour in his local time.

Correct, but unfortunately that’s only part of the issue here. There are potentially three (arguably even four) times to worry about:

1) TXP’s article posted timestamp
2) The time zone / DST setting on the browser/computer (mine when I post the article and a visitor’s when viewing the article)
3) The time zone / DST setting of the server that is running TXP

Consider this scenario: I want to invite people to a party in New York. It’s February now (DST is not in effect) and the party is in June (when DST is in effect). I post an article about it in TXP today and set the party date to be 15th June 2010 at 8pm. My computer is in London (5 hours ahead of New York). My ISP is in Germany (1 hour ahead of me in London, and 6 hours ahead of New York). What date is posted to the database? What date does someone in Australia who views my blog post about the party see? What date does someone see if viewing the article after April when DST has started in most parts of the world? What is the permlink when using year/month/day/title URL mode?

If you can answer those questions, you’re a better man than I am!

Consider smd_calendar sitting in between the database and the browser (also running on a server that might be in a different time zone to the one I’m working in). I have to read a custom field containing the date/time of an event and display it on a calendar and in an event list such that it accurately represents the true date of the event as intended by the author. What date/time do I display to the visitor? Do I need to take the time zone difference of the ISP/server into account or has the fact that it has already been calculated when the article was saved enough?

Of course, all this assumes that you stay with your original ISP. If you move hosts to a different time zone, all your articles might be out by a few hours until you correct them all.

TXP 4.2.0 tries to shield you from all this stuff by employing the tz_offset() and is_dst() functions when outputting and writing dates. I previously did some of this gubbins manually, which is partly why there are a few issues under 4.2.0 with this plugin. Since 4.2.0 does a lot of it automatically now, I need to revisit the plugin to take out the manual adjustments I made. I just need to figure out where to remove them and where — if at all — to leave them in place.

Time is a pain to deal with, as you say because it is relative to each person and there are many use cases: there’s plenty of further reading on the subject in this forum — particularly search out some of Michael Schlierbach’s posts (user: saccade) if you really want a mind scramble ;-)

Last edited by Bloke (2010-02-27 23:33:53)

rsilletti · 2010-02-28 01:09:28

Bloke I tried the approach with moving time settings on a local MAMP server. I found that the overall Alice in Wunderlund effect of moving both time settings inside TXP, and server settings simultaneously was interesting, but both incredibly confusing and prone to wishful thinking; it is amazing how simple it can be to get things to look right when they are in fact not. I opted out for writing a couple functions that would reflect what’s going on in the environment, for some of my own testing as well as your calendar plugin, and found that consistency in the settings impacting both the calendar plugin and the testing functions told me more than shuffling server settings. Of course, I would guess that your grasp of Apache servers is far better than mine – that’s not my strong suit.

PascalL · 2010-02-28 02:25:14

Consider this scenario: I want to invite people to a party in New York. It’s February now (DST is not in effect) and the party is in June (when DST is in effect). I post an article about it in TXP today and set the party date to be 15th June 2010 at 8pm. My computer is in London (5 hours ahead of New York). My ISP is in Germany (1 hour ahead of me in London, and 6 hours ahead of New York). What date is posted to the database? What date does someone in Australia who views my blog post about the party see? What date does someone see if viewing the article after April when DST has started in most parts of the world?

Ok, I think we have to split the question in three parts:

what date and time users who surf your site should see? Easy: the party takes place at 8pm in New York local time. That’s all. The fact that I live on the other side of the earth doesn’t change anything about that. Nor the fact that your ISP’s server is in Honolulu, the former being in Russia but you changed because it’s time system had all been messed up by mafia exactly the minute before dst adjustment. I insist: the time is still 15th June 2010 at 8pm. It’s a given fact. I still have to go over the ocean and know the exact local hour I have to be there! There, not here (at least in this use case)!. Now we know what to display. This leaves one problem: exactly when to consider the event is now past, and stop displaying it. More on this later.
what time and date should you put in your write tab? Not hard: you have combined everything with the local fastfood where you have invited your guests. They said 8pm in New York local time is fine. And they don’t mind that you called them in February, just when crossing the Cape Horn with your tiny boat, and that it must be breakfast time at home! Write down “15th June 2010 at 8pm”, everything else would be confusing as you’ve already lost your compas and would just like to go back home.
what time should be stocked in the database? two answers: the easy one, and the complicated.
1. The first, easy one. Take it as my agnostic and naive suggestion: Use custom field(s) to stock the raw date and time of the event, and don’t bother with the write tab’s posted date. There’s a problem: the tag <txp:posted /> will do very bad things to your custom fields content if you use them as fake posted date. It will try to adjust time taking into account a number of parameters, and you’ll have to negate this adjustment. You know this better than me. Nevermind: let’s not use <txp:posted /> ! (I start to feel some guns pointing to my neck here…) Just create a similar tag, let’s say <txp:smd_cal_posted />, which just displays the untouched dates! Those the user wants to post and the reader wants to read!
2. Second, the complicated way…

Wait, sorry, have to go to bed now, so I leave this for tomorrow, along with all the “more on this later” I’ve left down the road. Always push big problem to the next day. Let me know if this seems completely nonsensical at this point, and if I missed any obvious facts. Maybe this is not so complicated after all if we accept to cut down some complexity.

mrdale · 2010-03-18 16:16:04

Sorry for posting more on timezone/time offsets but I need to get this resolved one way or another.

My settings

TXP timezone: Los Angeles (-8 GMT)
TXP DST: On
Server timezone: GMT (0 GMT)

I have a page where I’m using:

<txp:smd_calendar /> to generate a small (big formatted small) calendar and
<txp:smd_article_event /> to handle a list of event excerpts using the <txp:posted /> tag in a form.

Here’s what happens:

If I post an article, on March 30 16:59:59 it shows:

March 30 in the calendar generated by by #1

March 30 in the list generated by by #2

If I post an article, on March 30 17:00:00 it shows:

March 31 in the calendar generated by by #1

March 30 in the list generated by by #2

How would I fix this? This is a situation reflected in all the calendars on all the sites I create. It’s just getting critical now cause I’m finishing a site that has a massive event section.

mrdale · 2010-03-20 03:57:52

bumpity?

Bloke · 2010-03-20 14:11:35

mrdale wrote:

If I post an article, on March 30 16:59:59 it shows: March 30 in the calendar… If I post an article, on March 30 17:00:00 it shows: March 31 in the calendar

Clearly that’s retarded due to braind-dead coding on my part.

At the moment, the two tags calculate things slightly differently, which is stupid. In my plugin refactorisation attempt I’m consolidating all the time generation / manipulation stuff into a bunch of common functions used by both smd_calendar and smd_article_event. That means they’re either both right (or both wrong) but they are at least consistently right or wrong :-)

I’ll see if I can get you an uber-beta drop by tomorrow to play with. Prod me by e-mail.

saccade · 2010-03-23 00:46:53

Is there any implemented way to show time of an event (hour, minute and seconds) if you’re using (custom) datefields?

I couldn’t find out if smd_cal_info can do it. There is only year, month, day mentioned.

Or did I stupidly miss something?

Textpattern CMS

Textpattern CMS support forum

#481 2010-02-27 03:18:21

Re: smd_calendar: complete schedule / event / calendar / diary

#482 2010-02-27 19:17:33

Re: smd_calendar: complete schedule / event / calendar / diary

#483 2010-02-27 20:19:17

Re: smd_calendar: complete schedule / event / calendar / diary

#484 2010-02-27 21:48:40

Re: smd_calendar: complete schedule / event / calendar / diary

#485 2010-02-27 22:32:16

Re: smd_calendar: complete schedule / event / calendar / diary

#486 2010-02-27 23:31:47

Re: smd_calendar: complete schedule / event / calendar / diary

#487 2010-02-28 01:09:28

Re: smd_calendar: complete schedule / event / calendar / diary

#488 2010-02-28 02:25:14

Re: smd_calendar: complete schedule / event / calendar / diary

#489 2010-03-18 16:16:04

Re: smd_calendar: complete schedule / event / calendar / diary

#490 2010-03-20 03:57:52

Re: smd_calendar: complete schedule / event / calendar / diary

#491 2010-03-20 14:11:35

Re: smd_calendar: complete schedule / event / calendar / diary

#492 2010-03-23 00:46:53

Re: smd_calendar: complete schedule / event / calendar / diary

Board footer