7 Replies Latest reply on Mar 6, 2018 10:06 PM by Sanford Whiteman

    Email Script Token Tests Correctly, but Fails to Default Value on Live Send

    Matthew Prince

      Hi All, hope you're having a delightful day.


      I'm attempting to build an email script token that will output the full date in 90 days from runtime.  After reading through other Nation pages, I created the following script modified from Jason Hamilton's answer here Dynamic date token for email :


      #set($dateInNinetyDays = $date.calendar) 


      This script consistently tests successfully via the 'Send Sample' feature within the intended email creative, but simultaneously consistently fails back to the default value when sending live.


      Does anyone know why this might be happening?

      Please and thank you!




        • Re: Email Script Token Tests Correctly, but Fails to Default Value on Live Send
          Sanford Whiteman

          First, you should always use timezone-aware dates (yes, even when you believe you're just adding full days). Follow the framework here: http://blog.teknkl.com/velocity-days-and-weeks/


          Second, you don't need to use hours * 24, use actual days. When you include the constants as in the blog post, it's




          Third, if you have a calendar object, you don't need its time property, you can the object directly to date.format:


          $date.format("full_date", $calNow, $defaultLocale, $defaultTimeZone)


          And finally, the {{my.token:default=whatever}} structure isn't actually supported w/Velocity tokens. Emit the default value from the script instead (i.e. if preconditions aren't met) and just include {{my.token}} in your email.


          If you make those adjustments, do you still see no output in the rendered email? How about in Preview-by-List? How about adding some debugging lines to output each intermediate variable? (P.S. I never use Send Sample to test VTL because it can give false assurances).

          2 of 2 people found this helpful
            • Re: Email Script Token Tests Correctly, but Fails to Default Value on Live Send
              Matthew Prince

              Thank you for the detailed reply Sanford.  Based on the framework within your blog article, I arrived at the following revision:


              #set( $defaultTimeZone = $date.getTimeZone().getTimeZone("America/New_York") )
              #set( $defaultLocale = $date.getLocale() )
              #set( $calNow = $date.getCalendar() )
              #set( $ret = $calNow.setTimeZone($defaultTimeZone) )
              #set( $calConst = $field.in($calNow) )
              #set( $ISO8601 = "yyyy-MM-dd'T'HH:mm:ss" )
              $date.format("full_date", $calNow, $defaultLocale, $defaultTimeZone)


              Does this appear to be better?  The Locale is English (United States) and timeZone is accurate.  Unfortunately, it appears my adjustments are incomplete, because I am indeed still seeing no output rendered in the final email.  I tested also using Preview-by-List, which tests successfully along with Send Sample and a live deployment to an internal microtest list.  Thanks also for your advise about Send Sample and the false assurances it can cause.  So, this revision and the initial version yield the same successful date output in Preview-by-List and a small internal test [and Send Sample], but equally fail to default/blank value upon live deployment to the test list.


              Somewhat as a curious aside; your Velocitips article mentions that you might be willing to expand a bit about the reasons why setting the IANA time zone is critical, would you mind doing so here please?