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.
This is fixed in latest SVN build, except [BUG-2563]
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.
I am in Pacific zone, and the latest SVN fix work fine, please try that version.
(mistake)
The bug is fixed in SVN, please try that version and give feedback, that is if you want.
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.
Where is it wrong?
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.
AGAIN >:(, this has been fixed in SVN, please check SVN and report.
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.
Oh crap, it's not BUG-2563. In that one the current date appears.
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.
Quote from: kitchin on July 16, 2009, 20:09:05 PM
Oh crap, it's not BUG-2563. In that one the current date appears.
Which one is?
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.
I tested few time with authorize.net and PayPal the date is fine, is your installation using latest SVN?
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.
And thanks for suffering through this bug with me.
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.
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.
Joomla doesn't have a Daylight saving time, once a year you have to change it manually.
Ah! Thanks again.
When you say "latest SVN build", what branch do you mean?
SVN builds should not be used on production/live sites http://dev.virtuemart.net/cb/proj/doc.do?doc_id=1328
Yeah, I know that, but what branch were you discussing here in this thread?
I don't understand what you mean by branch, the link above it for nightly build.
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"
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.
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.
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
Eric, there's not a bug fix for that, last time I checked. The fix is for card expiry dates. But my workaround will probably work for you. Three questions:
1. What time zone do you have Joomla set for? See: Site / Control Panel / Global Configuration / Server.
2. What time zone is your server? Use this to check: "<? print date('r'); ?>".
3. What time zone do you want for your orders?
The real fix would be for Virtuemart to store all times in UTC, then mod them on display. In my humble, etc., etc.
I was working on a fix to undo the problem just before display, but there were a lot of files to change. And I did not want to mess with how the data is stored. So I'm using Azores time to get the -1:00 offset I need.
We want the orders to work within the Pacific Time Zone.
Here is the server time stamp:
Wed, 29 Jul 2009 18:41:50 -0500
This was taken 4:41PM Pacific Time
Thanks!
Try setting Joomla time to "UTC -2:00 Mid-Atlantic".
Only new orders will be affected, if I recall correctly.
After daylight savings time goes off, you might need to change it by another hour, depending on your server.
Okay thanks...I will try it.
how can something SO IMPORTANT be so missed and so neglected.
Don't even get me started on non-inventory control for items in the store that are the same that need to be part of a kit...RE: Parent/Child Items et al
Thanks!
Eric
I have not learned how to use SVNs but since they aren't supposed to be used on a live site they wouldn't help me much anyway. I looked at what I thought was the code from a recent SVN but maybe I goofed because I did not find the change Kitchin mentions above where the "1" changed to a "15".
Anyway, that code is not in the ps_main.php file, it is in the ps_checkout.php file. The full path is:
administrator/components/com_virtuemart/classes/ps_checkout.php (approx. line 334)
So I made the change as Kitchin noted and re-tested my site. It works! I now have the correct credit card expiration dates showing in both the customer's email receipt and the VirtueMart admin.
As for the order dates and/or times being off, I found a fix that works for that at: http://forum.virtuemart.net/index.php?topic=50910.0 If you don't see it right away, search the page for timestamp.zip. Everything you need is in that zip file.
In addition, I was still off by one hour due to Daylight Savings Time. I had to set Joomla to Central Time and will change it back to Mountain Time when DST is over. This fix solved all my order dates and now with this new one from Kitchin, my credit card expirations are correct also.
Thanks Kitchin!
I have read this entire thread ands being a non progrmammer I guess I have a sense of where the errors are arising but don't have a clue what I neded to do to implement a fix. A zip file would be nice or at least a list of code lines that need to be amended would be nice. I like posts where the old code with approximate line number is printed followed by the revised code. It makes a cut and paste solution a little easier.
This back and forth about SVN and nightly builds is of little use for those of us who are not developers. I simply have a production site and need help with implementing a fix.
I am little surprised that this bug is considered "minor". Writing code to capture and store a critical pices of customer information is not at all helpful if the information is not stored and diplayed correctly. I would rather see the information purged than to have it displayed incorrectly giving the impression that it could be used at a later date without problems.
Would someone care to give a brief summary of what lines need to be modified to solve this?
Bruce
www.pepper-passion.com