installed uc_node_access module and used it to control access to cck nodes. When using the access limit of specified date, I noticed that after 7pm local (gmt -5) on day prior to expiration, the access would end. After getting into phpmyadmin and confirming the uc_node_access_expirations table entry for that access had disappeared, I started digging and found that uc_node_access was basing its expirations on gmt (line 384 in uc_node_access.module). This left me a dilemma, do I make my users think in gmt when they schedule a node access for purchase, or do I modify uc_node_access.module to be mktime vs gmmktime. I chose the latter option for now. This seems to be working fine for me at this point. Is there a down side to me modifying that line of code? Will this cause issues with other related nodes? If this is just a preference, can there be an option added to uc_node_access to allow a choice of gmt vs local for the governing time?
My main goal for creating this issue, was to allow others to find the reason, if they are experiencing the same behavior I was.
This module has been key to developing our pay per view usage on a site, thanks for developing it.

Comments

mardrop’s picture

mardrop commented
Title: Expiration Date » Expiration Date occurs prior to expected time
iva2k’s picture

iva2k commented

Why not expose time in the interface? Date API provides features to edit both date and time. This way admin can set expiration on specific time, like the last minute of a calendar year.

At a minimum and more importantly settings forms should follow Drupal's conventions. Current ones (upon inspecting few other modules) are honoring user's timezone on all the pages, and keep UTC in the database. So what missing is a conversion step UTC->user when data is put into the form, and user->UTC when data is put from form into the database.

This code tells what timezone to display dates in:

  if (variable_get('configurable_timezones', 1) && $user->uid && !empty($user->timezone_name)) {
    return $user->timezone_name;
  }
  else {
    $default = variable_get('date_default_timezone_name', '');
    return empty($default) ? 'UTC' : $default;
  }
jeremy.zerr’s picture

jeremy.zerr commented

@mardrop
Thanks for bring this issue up. For people looking for very close control over the time their nodes become available, having the difference between GMT and local not accounted for is a problem.

@iva2k
Thanks for diving in and taking a look at a few other modules. I agree with you, should always store non-timezone specific in database, then translate only when necessary. Sounds like a good change going forward, and maybe Date API integration some time in the future.

iva2k’s picture

iva2k commented

No worries on this one for me any more - I wrote new module uc_cck_access that covers date/time integration with Date module for this use case as well as many others.

jeremy.zerr’s picture

jeremy.zerr commented
Assigned: Unassigned » jeremy.zerr

I'll probably look at incorporating this too