nblgeoweb VIP
Total posts: 178
13 Авг 2014 00:04

I am experimenting with using Cobalt with the calendar template for records that are events. When I display a table of events (either after the calendar or with a seperate template) the events are listed using one of the built-in sort criteria. If I sort by event date, the first record in the table is either the earliest record or the latest record. I actually want to see the event closest to today's date and upcoming events but I also want to be able to access past events too. Is there a way to do this?

Последние изменения: 05 Сен 2014


Sergey
Total posts: 13,748
13 Авг 2014 11:18

nblgeoweb I actually want to see the event closest to today's date and upcoming events but I also want to be able to access past events too. Is there a way to do this?

This is only posible in calendar template. In other templates you can only list events like any other records.


nblgeoweb VIP
Total posts: 178
14 Авг 2014 18:59

Thanks for the quick reply, Sergey. I assumed that was going to be the answer but I thought I'd ask just in case I was missing something.

A possible solution to the problem would be to have a filter on date automatically applied that has a date range from today to some specified date in the future so that the list starts at today (or 1st of the current month, etc) and the user can change the filter if they want to see past records.

Is there a way to have a filter applied automatically as a default condition without the user manually specifying a filter themselves? Is that something I can code into my template somehow?


Sergey
Total posts: 13,748
15 Авг 2014 02:25

Please read this. may be you can figure out something.


pepperstreet VIP
Total posts: 3,837
15 Авг 2014 17:36

nblgeoweb I actually want to see the event closest to today's date and upcoming events but I also want to be able to access past events too

Alternatively, you might display UpComing and Expired with Cobalt's Records module.

This would require some thoughts about your event's dates... i.e. how they are going to be entered and stored. You already have noticed: List and module parameters for initial sorting order work with Cobalt's core dates (create, modify, expire).

The Calendar-Pack and its templates make use of 1 separate Date/Time field. By default it does not alter the core dates. The date field allows different entry modes for single dates, and even multiple dates. Additionally, the Calendar pack has a special parameter to utilize this date field. And it uses the Range-input template.
mj_cob_field_datetime_range_input

Headsup: Range input does not allow time entries!
mj_cob_field_datetime_range_no_time

The Calendar is a nice pack and cool display variant, but it might not suit all of your needs...


You may setup events in different ways, especially the date/time field overrides might come in handy:

A.) Core dates, do not alter them
B.) Core dates + 1 extra Date field for easier input, display and formatting. (days count, color codes etc.)
C.) 1 extra Date field which Overrides create date, optional override expire date (+1 day)
D.) 2 extra Date fields which Override create date and expire date. Both entered by user
E.) ? ...

Quick and dirty example for C.)

To keep it simple I used the existing date field, and set both dates: create and expire. I chose +1 day for expiration. This is just a quick way to let events expire and vanish from the list. (If you have exact timeframes and hours, i would choose 2 date fields with correct time input. It really depends...)

mj_cob_field_datetime_overrides

and configured 2 Records modules accordingly. Hence the different sorting order and What to show.

UpComing events:
mj_cob_module_records_future_params

Passed events:
mj_cob_module_records_expired_params

For demonstration purposes I kept it simple and placed the modules right above the list. (They could even be integrated into the markup/calendar template... so, they are hidden or collapsed in their own "tabs".)

mj_cob_module_records_future_expired_only

Maybe this helps ;)


techutopia
Total posts: 202
16 Авг 2014 01:47

Advisory ...

At : http://www.mintjoomla.com/download/joomla-3/category-items/4-downloads/14-packs.html

"This pack is free but require commercial filed ****Date and Time**** to be installed by default."

The "Date and Time" link is a 404.

Hope that helps,

Dale.


Sergey
Total posts: 13,748
17 Авг 2014 09:07

techutopia Advisory ...

At : http://www.mintjoomla.com/download/joomla-3/category-items/4-downloads/14-packs.html

"This pack is free but require commercial filed ****Date and Time**** to be installed by default."

The "Date and Time" link is a 404.

Hope that helps,

Thank you.


nblgeoweb VIP
Total posts: 178
28 Авг 2014 23:11

Thanks pepperstreet for your suggestion. It was very well explained. I wasn't aware of what the overrides for the date field did so I hadn't thought of this option. Yet another discovery about the amazing things Cobalt can do :)

There seems to be some issues with the overrides though - at least in my current version (8.573):

The expiry and create dates are always one day before the date of the event for a single date event. For a date range, the create date is set to one day before the event and the expiry is set to one day before the end of the date. I don't have anything specified for the modification values. I just have the overrides turned on. I expected the create and expiry dates to be exactly the same as my event date unless I specify a modification value.


Sergey
Total posts: 13,748
29 Авг 2014 04:25

nblgeoweb The expiry and create dates are always one day before the date of the event for a single date event

It is one day befoe in month view or real dates saved one day before?


nblgeoweb VIP
Total posts: 178
29 Авг 2014 12:25

The real dates are one day before. I turned on the display of create and expire dates in the table template to see the values.


pepperstreet VIP
Total posts: 3,837
29 Авг 2014 19:46

nblgeoweb The real dates are one day before

Did several tests with my previous example. Also setup a new copy of calendar pack. Tried date range and single inputs. Different list and article templates. Also had NO EXTRA days, no time input. Just set default OVERRIDES for create & expire core dates.

I couldn't re-create your issue and effect. The date is correct (in my tests).


Sergey
Total posts: 13,748
31 Авг 2014 22:36

This is surely because of server locale settings and Joomla timezone.


nblgeoweb VIP
Total posts: 178
02 Сен 2014 14:37

I think Sergey is on the right track so I did some more digging...

I checked and my server, Joomla, and php settings are all using the same timezone (CDT - America/Chicago). In this case, I'm using a date in my cobalt field with no time. The create and expire dates in the database are correct and time is set to 00:00:00. The create and expire times that show up in the front-end are 19:00:00 the day before, which just happens to be 5 hours before the correct date and my offset here is -5 hours. I'm guessing that there is somewhere in Cobalt where the dates/times are read from the database as local and then used in a timezone-aware function like PHP time() - or maybe the date/time from the DB is handled properly but the comparison to determine if a record expired is done with local time rather than UTC time.


Sergey
Total posts: 13,748
03 Сен 2014 06:52

nblgeoweb Joomla, and php settings are all using the same timezone (CDT - America/Chicago)

PHP have to be UTC. If PHP is CDT America/Chicago then do not use timezone in Joomla.

Otherwhise, I think that Joomla know nothing about timezone of the server. It's timezone parametrer just apply offcet to current server time. So it should be UTC.


nblgeoweb VIP
Total posts: 178
03 Сен 2014 14:33

All of my Joomla article create/modify date/times are correct with America/Chicago in PHP and America/Chicago in Joomla as well. My Cobalt records all have the correct last modified date/time as well. Joomla stores everything as UTC and uses the timezone set in Joomla to convert to local time (or whatever timezone is set fot the user). With my current PHP and Joomla timezone settings I think everything is working properly.

For my Cobalt records, all times (last modified, expire, create) are all UTC in the database, even when using override for create/expire and are displayed properly (full article and record listing). This is good and being done properly.

I guess the real problem here is not the override but that I'm not using times in my date field ("Allow Set Time" flag is set to "No") so Cobalt reasonably assumes 00:00:00 for the time. With a negative UTC, this causes the date to be one day earlier when displayed in the local timezone. I played with the calendar template and my events display one day early on the calendar as well.

If I was using times in my date field then it wouldn't be a problem because the time I specify would be converted to/from UTC and handled properly. There is no problem if the UTC offset is 0 or +.

In this case I think the only thing Cobalt could do to solve the problem is to treat the UTC value for my date field in the database as local if the "Allow Set Time" flag is set to "No" in a "Date and Time" field.


Sergey
Total posts: 13,748
04 Сен 2014 04:12

What id I change 00:00:00 to 00:00:01?


nblgeoweb VIP
Total posts: 178
04 Сен 2014 12:52

If you change it to 00:00:01 then when the UTC offset is applied and it's still the day before. In my case the local time would be 19:00:01 the day before.

10:00:00 would work (but see below). That would cause problems with UTC-11 and UTC-12 which include a very small number of very small pacific islands. 11:00:00 wouldn't work because New Zealand does use Daylight time (UTC+13)

http://en.wikipedia.org/wiki/UTC %E2%88%9212:00 http://en.wikipedia.org/wiki/UTC %E2%88%9211:00

When displaying a record as expired or not does Cobalt just use the date or the time as well? I assume it uses the time too. If it uses the time then you will still see some strange behaviour on the day of expiry. For example, if I have a record with a UTC expiry time of 10:00:00 then it will not be expired before 5:00:00 local (UTC-5). Most people wouldn't notice that here but closer to you it would be more of an issue. The same issue shows up whether you use override or not.

The choice of 00:00:00 is a good one but somehow that needs to be treated as local rather than UTC when expiring records. You could make the expiry 00:00:00 local (19:00:00UTC the day before in my case). That would always be correct as long as no one ever changed the timezone of the server (Joomla?).


Sergey
Total posts: 13,748
05 Сен 2014 00:51

Do you have proposed change in th code?

Работает на Cobalt