Expiry date bug, order date bug, BUG-2563

[aravot]

I tested few time with authorize.net and PayPal the date is fine, is your installation using latest SVN?

[kitchin]

OK, you are right.

I got my diff backwards.  The SVN version of vmFormatDate() fixes the expiry issue!!!!

If anyone is interested, it is now more or less a strftime() wrapper.  In VM 1.1.13 it used something called JHTML::_('date',...) from Joomla 1.5.

The strftime() is correct because the expiry date is created with mktime().  Both use the same time zone offset.

[kitchin]

And thanks for suffering through this bug with me.

[kitchin]

Well, I still see some bad code in SVN, such as this:


<td><?php echo vmFormatDate( $db->f("cdate")+$mosConfig_offset);?></td>

(Line 80, in order.order_print.php 1481 2008-07-21 19:11:07Z)

$mosConfig_offset is hours, but f("cdate") is seconds.

Even ignoring that, it still seems to me that 'cdate' and 'mdate' are broken in SVN. But 'order_payment_expire' is fixed.

Here is what is going on.

The values stored for 'cdate' and 'mdate' are...


$timestamp = time() + ($mosConfig_offset*60*60);

(Line 904 in ps_checkout.php 1451 2008-07-04 19:55:31Z)

The $mosConfig_offset is the Joomla time zone offset, configuarble in the Joomla admin panel, if I understand correctly. It is not adjusted for DST.  For example, Chicago has $mosConfig_offset=-6, all year, CST/CDT.

But in the new SVN VirtueMart files, vmFormatDate() no longer uses the Joomla offset.  Instead, it uses local server time.  For example, my server is set for New York, -5 EST and -4 EDT.

In general, local server time is applied by mktime(), strftime(), date(), and the new vmFormatDate().  The mktime() subtracts, the others add, so they complement each other.

Since SVN VirtueMart still stores timestamps adjusted by Joomla time, but displays them in server time, there are problems.

One fix, for display, is to subtract Joomla time and then use either strftime() or the new vmFormatDate().  So you get local server time.  And it is correct in every season.

A better fix might be to try to get Joomla time. But adjust it for DST.

Here is how to get Joomla time (in my case, Chicago time):


echo gmstrftime($vendor_date_format, $db->f("cdate"));


Exactly the same as vmFormatDate(), but use gmstrftime() instead of strftime().  Since the 'cdate' timestamp is already adjusted for timezone, gmstrftime() is the correct function to display it.

That gives us Joomla time.  But it does not do DST.  To get that, adjust the code by using the date('I',...) function, which is 1 for daylight savings time, and 0 for standard time.


echo gmstrftime($vendor_date_format, $db->f("cdate") + (date('I', $db->f("cdate")) ? 3600 : 0));


Without changing the stored values in the database, that's the best I have come up with.

[kitchin]

And the DST aspect is really just applying the server's idea of DST, so which it assumes corresponds with the DST rules in the Joomla time zone.  For me, that's New York vs. Chicago, which have the same DST rules except twice a year for an hour.  A little flaky, that part.

[aravot]

Joomla doesn't have a Daylight saving time, once a year you have to change it manually.

[kitchin]

Ah! Thanks again.

[kitchin]

When you say "latest SVN build", what branch do you mean?

[aravot]

SVN builds should not be used on production/live sites http://dev.virtuemart.net/cb/proj/doc.do?doc_id=1328

[kitchin]

Yeah, I know that, but what branch were you discussing here in this thread?

[aravot]

I don't understand what you mean by branch, the link above it for nightly build.

[kitchin]

I checked out the SVN repository.  I couldn't find a recent nightly build.  You said it was "fixed in SVN", so that is what I am asking.  Which part of SVN?  I checked out

trunk
branches/virtuemart-1.1
branches/virtuemart-1.2


Note also, the comment on line 333 of
* @version $Id: ps_checkout.php 1830 2009-06-26 20:52:15Z Aravot $
says "default the day to the 1st".
It should say "default the day to the 15th"

[kitchin]

Until the order dates are fixed, the best workaround for users is probably to set Joomla time to Greenwich mean, in the admin panel.

Then at at least you get system local time for the order dates, instead of the timezones applied twice.  Even in the latest SVN version, the order date is offset both by the system timezone AND the Joomla timezone.  This workaround would not fix old orders already stored, though.

[kitchin]

I'm actually using Azores time (-1:00) to account for the difference between my server time (New York) and the store location (Chicago)!

That, plus the expiry date fix in the SVN, takes care of everything for me.  The ~6 second bug in the order date display is not important (order.order_print.php).

The SVN expiry bug fix is simply this:
administrator/components/com_virtuemart/classes/ps_main.php

-$expire_timestamp = @mktime(0,0,0,$_SESSION["ccdata"]["order_payment_expire_month"], 1,$_SESSION["ccdata"]["order_payment_expire_year"]);
+$expire_timestamp = @mktime(0,0,0,$_SESSION["ccdata"]["order_payment_expire_month"], 15,$_SESSION["ccdata"]["order_payment_expire_year"]);

So the expiry dates are stored at the 15th of the month instead of the first, which wipes out any time zone issue.  Looking at old records would still display wrong, but you could use the code I posted adding two days for that purpose.

Still unanswered is my question about which SVN development branch Aravot meant, but I think the answer is 1.1.  The "trunk" branch is actually quite old.

[Eric Brown]

My order dates are off by one day back.  Is this the same issue.  and where on earth to I go to get the info for the BUG fix so I can apply it?

Eric