Domains registered on February 29th

[Troy]

This was already discussed in this closed thread, but no mention was made as to whether this was officially acknowledged as a bug.

 

I have a domain that was registered via the Enom module on February 29th, 2008. The dates were set up incorrectly as follows:

 

Expiration: 03/01/2009, but should have been 02/28/2009.

 

Next due: 00/00/2010, should have been 02/28/2008.

 

Seems like a bug with leap year logic. Luckily, there are 3.75 years left to get it fixed.

[penguin]

As you're using Enom, I'd guess that if you use the new Enom sync script that is now available from v3.6.1, this will not then be an issue as the domain will have the correct expiry details obtained from Enom automaically

[chickendippers]

...or DirectI

[Troy]

Well, yeah, I know there are a variety of ways to correct the data. I'm just pointing out that there is a bug in the registration code that should be corrected.

 

Since you mention it chickendippers - have you actually used the DirectI sync, and then gone back and compared the DirectI dates after running the sync? Here's why I ask:

 

DirectI stores a Date AND Time for expiration. If you've ever noticed, and depending on your time zone, you may show 05/31/2008 as an expiration date in WHMCS, whereas in whois you see 06/01/2008.

 

We're UTC -5 at the moment. If a customer registers a domain name at 8:00PM our time today, the actual expiration time at DirectI will show as 1:00AM tomorrow (UTC).

 

I am concerned that the sync script may not take into consideration that DirectI takes expiration down to the minute, and I'll end up with some dates that are off. For this reason, I haven't tried to use it yet.

 

If there is a problem, what will then happen is, for the above example, if the customer doesn't renew early, the domain will actually expire before WHMCS renews it. We run the cron at 1PM - (more likely that authnet will always be up at that time) - so if the date is set to whatever DirectI spits out in UTC, we could have a domain expire at 8PM, and not get renewed by WHMCS until 17 hours later, 1PM the following day.

[Troy]

Well, having tested a single domain that expires in the first couple hours UTC, seems the DirectI sync does set the date correctly to the previous day for our time zone.

[Matt]

And in answer to the original question, there doesn't appear to be a bug that means the data is set wrong for domains registered during the leap year day - not by WHMCS anyway. All date calculations are done by PHP so should there be any errors, it would be the PHP date manipulation tools that have them and then I would suspect only certain PHP versions are affected. Setting the next due to the 1st March would be the full 365 days (1 year).

 

Matt

[Troy]

Setting to March 1st doesn't match what the registrar set the due date to, so if nothing else, the logic should do whatever the registrar is doing. We obviously should have the correct expiry date, though as has been mentioned the sync script can correct that.

 

However, the next due date was set to 00/00/2010 instead of 02/28/2009, (or 03/01/2009 if WHMCS doesn't set the date exactly like the registrar). Surely there is a error there?