Business Catalyst Secure Zone Expiration Dates Demystified

Curious about how secure zone expiry works? I had to figure it out for a recent API-based BC application I wrote. Here are some of my findings...

Tuesday, January 8, 2013 - Posted by Erick Stubbs to Technical How-tos

I'd like to begin this post by introducing myself.

My name is Erick Stubbs and I work for uGurus LLC, which does business in Denver, Colorado where we use Mountain Standard Time, except for when we use Mountain Daylight Time.

One of our products is a website called; hosted on servers located in New Jersey which follows Eastern Standard Time, and sometimes Eastern Daylight Time.

Those servers run software called Business Catalyst which is configured to host our website using Mountain Time.

Business Catalyst was created and is maintained by computer scientists and engineers who work in Bucharest Romania where they observe Eastern European Time who work for a company called Adobe which is based in San Jose California where they use Pacific Time.

While Business Catalyst is a global-ready product and operates in time zones all over the world, there are parts that are still tied to it's roots in Sydney where they use Eastern Daylight and Eastern Standard Time; the Australian version, not to be confused with the USA version of Eastern Time. However Business Catalyst more closely follows the folks in Brisbane, Australia who don't observe daylight time at all.

As I said, we have a website, and people pay us on a monthly basis to gain access to our content.  This system is supported by 2 different payment processors. One of these is built into BC and usually does what the rest of BC does with regards to time zones. The other is maintained by a company called Recurly who does business in Pacific Time, and reports payments to me in Coordinated Universal Time (UTC).

These systems are linked together by software which runs on servers in San Antonio Texas where they use Centeral Standard or Central Daylight Time, but are configured to use UTC.

Then there is my customer, who lives everywhere in the world and uses global everywhere anywhere time.

Finally there is my business model which is to collect payments from my customers and grant them access to our website. We charge them periodically and extend their access for a month, or 30 days, or 4 weeks, but sometimes its 28 days, and others its 31.

So long as a paying customer always has access to our site they are happy, so long as a non-paying customer never has access to our site, I'm happy.

Which brings me to Monday, when a customer named Zeb called me to sign up. They wanted to give me their credit card and gain access to my site for a month, it was 4:20pm somewhere in the world and all I had to do was figure out when to make their secure zone membership expire.

Luckily for me, the rules regarding time zones, secure zones, and Business Catalyst aren't documented anywhere, have changed over the course of the product, and from time to time exhibit bugs which can affect some of our members, but not others.

But the hommies at Adobe are fine folk, and after working it out, fixing some bugs, and doing some tests I can now take Zeb's money and set his Secure Zone Expiration Date.

Here is how it all works

A Secure Zone expiration date represents the point in time when a users Secure Zone access expires. 

Meaning, if the current date and time is less than the Secure Zone expiration date and time, the user will have access. If the current date and time is greater than or equal to the Secure Zone expiration date and time, the user will not have access and be considered expired. This value is precise down to the second.

When viewing a user's Secure Zone expiration date in the BC Admin area, the time component of the Secure Zone expiration date is not shown; instead only the date will be shown. The date component will be shown with regards to the time zone setting of the BC site.

When manually setting a Secure Zone expiration date using the /adminconsole, the date should be set with respect to the site's local time zone.  A time component cannot be set by the admin user, as such the time component will always be 12:00:00 AM on the date specified in the site's local time zone.

When querying the SecureZone expiration date using the BC API, both the date and time component will be returned in string form *'MM/dd/yyyy hh:mm:ss tt'.  This value has an implicit UTC +10:00:00 offset. This value corresponds to Australian "Eastern Standard Time".  "Eastern Daylight Time" is never used, it will always use "Eastern Standard Time" with a UTC offset of +10:00:00.

When using the API to set a Secure Zone expiration date, the value passed to the API must be in the string form *'MM/dd/yyyy hh:mm:ss tt'. The value specified will be treated by BC as having an implicit UTC +10:00:00 offset. Meaning if you wish to expire a user on December 15th, 2012 at 7:45pm Mountain Standard Time, this value should first be converted to UTC +10:00:00 before passing it through the API.

When working with the API and converting between time zones, 'Australia/Brisbane' should be used when working with Olson time zones, and when working with Windows time zones the 'E. Australia Standard Time' system time zone should be used.

EX: TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById('E. Australia Standard Time');

* The format specifiers used here are documented at:

comments powered by Disqus