Expiry date bug, order date bug, BUG-2563

[kitchin]

Our expiry dates were correct in email, but off by one month is the admin order display.  Also, the order date is off by about half a day.  I figured it out and patched it.  Maybe this has something to do with the new PHP5 server timezone stuff?

See also: [BUG-2563]  -   Wrong credit card expiration date in user Account Maintenance.

These lines in VM 1.13 are definitely wrong or suspect:


////////////////////////////////////
// administrator/components/com_virtuemart/order.order_print.php, line 84:
////////////////////////////////////
<td><?php echo vmFormatDate( $db->f("cdate")+$mosConfig_offset);?></td>
// Definitely wrong, because $mosConfig_offset is *seconds* not *hours*.
// In my config, it is off by (2 * $mosConfig_offset) hours.



////////////////////////////////////
// administrator/components/com_virtuemart/order.order_print.php, line 590:
////////////////////////////////////
<td width="17%"><?php echo vmFormatDate( $dbpm->f("order_payment_expire"), '%b-%Y'); ?></td>
// For me, off by $mosConfig_offset hours, which in the Western Hemisphere
// is negative, pushing the date back into the previous month.
// (Expirys are timestamps of midnight on the first day of the month.)



////////////////////////////////////
// administrator/components/com_virtuemart/order.order_printdetails.php, line 64:
////////////////////////////////////
<td><?php echo vmFormatDate( $db->f("cdate")); ?></td>
// In my config, it is off by (2 * $mosConfig_offset) hours, as above.



////////////////////////////////////
// administrator/components/com_virtuemart/order.order_printdetails.php, line 405:
////////////////////////////////////
<td><?php echo vmFormatDate($dbpm->f("order_payment_expire"), '%b-%Y'); ?> </td>
// Off by $mosConfig_offset hours, as above.


These are my fixes:


// The $db->f("cdate") lines:
// Twice the time zone.
echo vmFormatDate( $db->f("cdate") - 7200 * $mosConfig_offset );

// The $dbpm->f("order_payment_expire") lines:
// Fix: add two days (172800 seconds).
// Only the month and year matter, and the timestamp is the first of the month.
// This is the safest, easiest way.
echo vmFormatDate( 172800 + $dbpm->f("order_payment_expire"), '%b-%Y');

// Alternative fix #1: subtract the offset, to override what vmFormatDate does:
// echo vmFormatDate( $dbpm->f("order_payment_expire") - 3600 * $mosConfig_offset, '%b-%Y');

// Alternative fix #2: old style, what VirtueMart once used:
// echo strftime("%m - %Y", $dbpm->f("order_payment_expire"));

// Do the alternatives work in the Eastern Hemisphere (TZ>0) and with DST?


I am still investigating a few issues and some more files.  I know the emails have the wrong order date, too.

[aravot]

This is fixed in latest SVN build, except [BUG-2563]

[kitchin]

Maybe the developers are in a positive time zone (Eurasia, Africa, Australia...).  You only see the expiry bug in the Western Hemisphere, where $mosConfig_offset < 0.  As long as the expiry date is stored as midnight of the first day of the month, my fix of adding two days will work.

The other fix, for the order date, depends very specifically on what they are doing about

vmFormatDate()

and the fact that the timestamps are stored in the database with a timezone offset, instead UTC.

[aravot]

I am in Pacific zone, and the latest SVN fix work fine, please try that version.

[kitchin]

(mistake)

[aravot]

The bug is fixed in SVN, please try that version and give feedback, that is if you want.

[kitchin]

The expiry bug is not fixed, as far as I can tell.  That is BUG-2563.  I looked at the new SVN code.

It should be rated a bit higher than "Minor" in my opinion.  Much easier to fix than the other bug was, anyway!

It is the expiry bug which only occurs in a negative time zone, such as the Americas, not the cdate bug.

[aravot]

Where is it wrong?

[kitchin]

Wrong credit card expiration date in user Account Maintenance.
page=order.order_print
page=order.order_printdetails

It is correct in the email sent to the merchant, because that page still uses strftime() instead of vmFormatDate(), in VM 1.1.13.

In the SVN trunk version, I just looked at the relevant files, since I don't have time to set up a test bed to run a non-stable version.  I did apply the new version of vmFormatDate(), but that did not change anything.

[aravot]

AGAIN  , this has been fixed in SVN, please check SVN and report.

[kitchin]

Don't frowny me! I'm just trying to help, and BUG-2563 is still marked unresolved, and I don't see an obvious fix in SVN.  If I have time to run a test bed, I will.

[kitchin]

Oh crap, it's not BUG-2563.  In that one the current date appears.

[aravot]

I am frowning because you keep repeating the same thing without even testing the SVN version, I understand you are trying to help, all help is welcomed and I thank you for it.

Bug-2563 is unresolved because of other reason which is commented, did you read the comment.

[aravot]

Oh crap, it's not BUG-2563.  In that one the current date appears.

Which one is?

[kitchin]

Well, in my situation the expiry date is off by one month.  I don't see that in BUG-2563.

What is your date_default_timezone_get()?
Mine is "America/New_York" on the SSL side, and "EST5EDT" on the non-secure, which has a slightly different version of PHP5/Apache.

My $mosConfig_offset==-6 because the store is in Central Time (U.S.), Joomla settting.