Open/Close dates

Changed to a bug report as there is functionality here that currently does not work correctly. Things to fix:

• Fully implement new Forms API interface.
• Fix validation as it currently won't let a user choose valid dates.
• Use timestamps on the back end and move date math into the module instead of in the databse (db abstraction portability issue).
• Make it so that expired quizzes cannot be taken.

+1 for optional date range

I have code that I think will work for all of this, but I'm currently suffering from trying to keep all these patches in the queue straight. I'll try to get my code fixed tomorrow.

Subscribing. We've been thinking about this same issue for the Decisions module, so I would be interested in potentially using whatever solution you guys come up with.

This patch does the following:

• Changed timestamp for when a quiz is started and finished to use unix timestamps. These are recorded based on gmt 0, accounting for user and site timezone settings.
• Changed timestamp for when a quiz is open and closed to use unix timestamps. These are recorded based on gmt 0, accounting for user and site timezone settings.
• Changes all DATETIME database columns to use INT(10) instead.
• Adds a quiz_always column to note quizzes that ignore open and close dates.
• Changed the name of open and close columns in table quiz to quiz_open and qiuz_close. These seemed like things that could easily conflict with other modules.
• Changed the open and close form elements to use form_date()
• Added form element for the "always" checkbox.
• Wrapped these form elements in an "Availability" fieldset
• The validation check to see if the close date is before the open date now works as intended.
• Adjusted theme_quiz_view to use new date format.
• Adjusted theme_quiz_view to check for the "always" flag. If present, it does not show any of the open and close information and just says that the quiz is always available.
• Added a check in quiz_start_actions to see if this quiz is available. Note that those with the permission 'create quiz' can take the quiz anyway.
• Added an include file called quiz_datetime.inc that holds most of the timezone logic. These functions are based on event code.

I'll admit that the include is not ideal, but until drupal has better timezone calculation and dst support in core, I think it's the best we are going to do short of requiring that event.module be installed.

In the context of a global classroom environment, it seems important to take into account the user’s timezone for purposes of determining when a quiz is no longer available. Re-reading the comments above, I noticed that webchick mentioned being able to set a time on the quiz, as well. The current timezone functions should be able to handle this, but a few tweaks to it and the form would be required. Ideally, a core function called something like form_timestamp() would available in the future. (I’m not sure if there is a 5.0 function along these lines.)

If anyone has a better idea on handling this or suggestions, I’m all ears.

(Chris: Not sure if this would end up working for you or not.)

Looks like I lost my patch from the previous post. Here it is.

Reviewing the patch, it looks like I missed a call to NOW(). I'm going to double check everything and possiblly put up a new patch tomorrow.

not following all the issue will make me lost!
two month earlier (webchick @ http://drupal.org/node/73607 )

Fields representing times and dates are switched to DATETIME instead of INTEGER (for UNIX timestamp) in order to help with date range calculation

and now you are back to INT ? :-/

+1 for optional start/end date : it's a great thing imho

About TZ, Sean B Fuller noticed :

In the context of a global classroom environment, it seems important to take into account the user’s timezone for purposes of determining when a quiz is no longer available. Re-reading the comments above, I noticed that webchick mentioned being able to set a time on the quiz, as well. The current timezone functions should be able to handle this, but a few tweaks to it and the form would be required. Ideally, a core function called something like form_timestamp() would available in the future. (I’m not sure if there is a 5.0 function along these lines.)

But i can remember that my Drupal users can set their TZ in a "Locale settings" from their profile, while the server (global) TZ is set via the configuration section (admin settings or something like that). I think core use the functionality (every user has time displayed according to it's timezone and his prefered format -not sure for the format, maybe it's global) for comments and for fora posts. note sure, but i'll put a look into those files. maybe webchick can suggest some place to look for that information ? he knows documentation better than us (i presume)
btw good job everybody. and think event module use the same tricks... i'll test the patch this w-e if i have some few time.

Updates version. I fixed one of the calls to NOW() that I had missed and replaced it with a call to time(). I also realized a few errors in my time, date and time zone calculations, so everything should be working now.

One thing I added was a message on the node_view for students that gives feedback on the availability of the quiz. If it is set to always, there is no feedback. If the quiz is not open yet, going to close, or closed, the student gets that message.

This was done because quizzes are set to close at midnight for the quiz author. For example, a teacher in GMT -5 sets a quiz to close on January 25th. The system sets a timestamp for that user based on midnight in GMT -5. A student in London (GMT 0) will get feedback that the quiz closes at 5:00 in the morning that day.

Please note that as DST is not accounted for in core, DST is not accounted for here. This is a dupal-wide issue that seems out of scope for this patch.

Everything seems to be working great now.

Committed to HEAD.

offset is set to zero! should not :(

just another idea: do not only shout error when close date ealier than open date; swap them..