[fixed] CPGNuCalendar 2.1 and Time Reply to topic

It appears that 2.1 displays the sever's local time EXCLUDING the daylight savings/summertime (if in force). I think this is correct, as running both server and browser on same PC gives me a 1 hour time diff - it being summer now here - are at least what passes for summer here.

So presumably the calendar has no support for seasonal clock change and no 'extra' or 'missing' hour for the clock back and clock forward days?

Asking because I'm trying to interface to CPGNuCalendar which means I'm effectively passing in an Epoch time (although I realise that in practice CPGNuCalendar is far more liberal than just Epoch in its use of time representations - are any 2 stored the same way? )

The start/end times become critical as soon as you support whole-day events, as 1 hour off makes it a 2-day event (starting at 23:00 day before or ending at 01:00 day after, instead of 00:00 - 00:00).

So I guess I'll have to "correct" for start/end times based on the server's dst - unless you remember a point at which I could patch CPGNuCalendar 2.1 to include server dst into its "Sever time"?

The latter would give a 1hr error on 2 days of the year (dst change), but I'm thinking that might be more comprehensible to visitors than showing clock off by 1 hour for part of each year... Difficult stuff...

To be clear to all I'm not complaining, or asking for changes, just trying to determine best way for me to go forward. Having CPGNuCalendar 2.1 run on server time (with/without dst) means I'm down to only an hour mismatch worst case, not the TimeZone diff that could occur on earlier versions not hosted on UTC0 servers. Thanks for the update, Phoenix. Diff'ing the code to apply my few updates I can see that you've addressed a lot of code changes.

I must admit, I was prepared to put up with the 1 hour discrepancy if it occurred.

I had expected DST to be automatically compensated for when using date_default_timezone_set(), which appeared to be the case in my tests on an *nix server. If this proves to be incorrect, I'll have to delve deeper , or just give up and port something else since ADODB has its limitations.

My intent was to be able to reflect "website" time, whatever the webmaster wanted that to be, regardless of where his server was located, and my tests so far indicate that has been achieved - the change provides website time as required, whether that be in Europe, Australia or wherever, despite the server being in the US.

At least under PHP5 we can make that time shift without it affecting any other programs, unlike PHP4 where the only option was putenv() which then stuffed up forum time for that same browser session.

Unfortunately, CPGNuCal still has some other limitations
- try a 6 hour event starting at 20:00 on a day
- annual events like the first Sunday in September work fine, until that first day is the first of the month.

Most of the other code changes are just tidying up code aesthetics, but at least I now have miscellaneous dates displayed in meaningful terms now i.e. where it was previously 05/07/2009 it now says 07 May 2009, so I have removed the ambiguity of US times.

Longer term, I'm looking at other porting options - there is only so much we can do with ADODB functions.

I'm interfacing with CPGNuCalendar by updating the db tuples directly - much like discussThis did for Forums.

So I'm insulated from the vagaries of CPGNuCalendar's math - although I have to convert to its varied date/time formats. Internal to Pro_News it's all Epoch time, with TZ and dst included. So I work out the corrected start end times first, then convert to CPGNuC date format and store.

I was doing all the local time in DF functions plus mktime(), except for 1 local time problem (reported) so I modified a routine and added a copy to Pro_News. (I believe L10N::date() was adding the dst in twice.) No experience in ADODB.

So now that you have the TZ correct, I think I'll just have to correct out the dst (e.g. if dst is in force but you plan an event in winter it will be 1 hour adrift), and then feed to CPGNuC.

I'll test some more, but my first basic test was to run, under XAMPP on my Ubuntu box with the server code and the browser all on the same system. Should give same time to both, no? I'm on GMT+dst currently so expected times to match...

What happens if you call L10N::is_dst() after you call on date_default_timezone_set()?

OK, tracing back through the code, and found a few things:

One, it's not L10N::is_dst that one should use, but a higher function in L10N class.

In modules/CPGNuCalendar/includes/functions.inc the function board_date() shown as the Local Time is based on is_user(). So if I log off and redisplay the Calender page then the times match, but they are now both off by the 1 hour "Spring Forward" summer time. So the deficit most likely is dst.

The Server "Calendar" time displayed above is obtained from adodb-time.inc, and so searching reveals that the code for dst (line 1059) executes only if function adodb_daylight_sv exists. It doesn't. And on line 294 all is revealed.

So it ought to be possible to call on L10N::in_dst() in some fashion to provide that result except ... I can't see any code anywhere that determines the region for the server. It is arrived at for the user somehow - from the timezone? - and placed in the userinfo.

More research needed, when time permits...

I make no attempt to align the calendar with user times - for now I simply display the difference, using board_date(), to the current website time - been down that track already in the ill-fated v2.0.7 and ended up with too many issues trying to match up with ADODB.

Already looked at adodb_daylight_sv() - it could be evoked but won't really provide a satisfactory adjustment and certainly won't resolve any user variance. ADODB makes no attempt to compensate for any user factor.

L10N works on the user preferences in Your_Account and places everything relative to GMT.

The only way I see around the issues between ADODB, L10N and server time is to use PHP5 to set server time to GMT and work everything from there, but it's a lot of work that I'm not prepared to go through just yet.

Oops!

Never mind the above.

Undaunted, this morning I went to add a Time Zone field to CPGNuCalendar > Config and discovered that you've added 1! And worse that it defaults to first entry rather than GMT. Seems that 'Africa - Abidjan' is 1 hour ahead of London during the summer at least...

Set it to 'Europe - London' and all is good. PHP5 - 5.2.5 anyway - does get dst from server.

I did look through the Config options when I upgraded, just never noticed.

Couple of FYI's while I'm here: The new 'Calendar' and 'Your time' texts on the Calendar main page didn't make it into the language file - easily fixed by any user who wants to change them.

And I didn't get email notifications for any posts to this thread, although I seem to be set up correctly in Preferences, and I did get them for PM.

Sorry for the red herring yesterday, but I've learnt a lot more about how PHP and DF handle dst now.

Phoenix wrote

v2.1.0 released - PHP5 only - time for people to move on so we can take advantage of PHP5.

Still monthly/yearly events don't work, if you use the "On the first/second/third ... "- option

events i.e. on every 13. of the month work fine

(Error occurs with Version 2.0.6. and PHP 4 and also with 2.1.0 under PHP 5)

The only issue I encounter is one I mentioned in an earlier post and exists in 2.0.6 as well

Phoenix wrote

annual events like the first Sunday in September work fine, until that first day is the first of the month.

Otherwise, monthly and annual events seem to be fine.

Phoenix wrote

The only issue I encounter is one I mentioned in an earlier post and exists in 2.0.6 as well

Phoenix wrote

annual events like the first Sunday in September work fine, until that first day is the first of the month.

Otherwise, monthly and annual events seem to be fine.

F*** I just don't get it ...

I tried both versions (2.0.6/2.1.0) on different DF-installations (fresh and updated), different PHP (4.4 & 5.2.) and different hosts and I just can't get this mothly-thing to work

edit :

argh ! Fund it ... CPGNuCalendar has problems with the german language file ... it stores the german erster/zweiter/dritter, Montag/Dienstag/Mittwoch instead of the english first/second/third, monday/tuesday/wednesday in the database ...

Glad you found it - I'll have to look at structures and see how we can still preserve the database values yet still provide for translations.

I'm tinkering with another Calendar to get around the limitations of ADODB, but that still has a long way to go.

Phoenix wrote

Glad you found it - I'll have to look at structures and see how we can still preserve the database values yet still provide for translations.

I'm tinkering with another Calendar to get around the limitations of ADODB, but that still has a long way to go.

Well, I haven't had time to look at the code, but I think the easiest way would be, to alter the code so not the placeholders (_FIRST, _SECOND, or rather the corresponding words from the language file) but the english First/Second are saved in the db when adding a recurring event.

No changes to the database and it should work with every language ...