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) 
$dateInNinetyDays.add(10,2160) 
$date.format('full_date',$dateInNinetyDays.time)

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!

-MP

[SanfordWhiteman]

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

$calNow.add($calConst.DATE,90)

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).

[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" )
$calNow.add($calConst.DATE,90)
$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?

Cheers.

-MP

[SanfordWhiteman]

but equally fail to default/blank value upon live deployment to the test list.

What do you see if you output

$date
$date.getCalendar()

in a real email?  I wonder if there's something amiss with your instance's Velocity config in particular (it happens).

... the reasons why setting the IANA time zone is critical, would you mind doing so here please?

Because your pod timezone (i.e. JVM timezone) isn't the same as your instance timezone: it's typically CST for everyone. Date-like strings will be parsed in the JVM timezone by default, and new Date/Calendar instances will also inherit the pod timezone unless you tell it otherwise.  You need to control the tz or else you will get really hard-to-debug errors when crossing midnight.

[Matthew_Prince]

In a live email, I see blank value; but in Preview-by-List I see:

Mar 6, 2018 10:44:18 PM
java.util.GregorianCalendar[time=1520397858674,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="CST6CDT",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=149,lastRule=java.util.SimpleTimeZone[id=CST6CDT,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2018,MONTH=2,WEEK_OF_YEAR=10,WEEK_OF_MONTH=2,DAY_OF_MONTH=6,DAY_OF_YEAR=65,DAY_OF_WEEK=3,DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=10,HOUR_OF_DAY=22,MINUTE=44,SECOND=18,MILLISECOND=674,ZONE_OFFSET=-21600000,DST_OFFSET=0]

I notice the reference to CST6CDT.  Am I able to edit the Velocity config, if that is the problem?

Thanks again for the detailed thoughts and insight regarding setting the IANA time zone.

-MP

[SanfordWhiteman]

Try something else for me, again strange but based on experience: send a triggered email instead of batch (click-and-send in the UI is a batch equivalent).

[Matthew_Prince]

Sure thing; I activated a triggered email instead of batch - but the output is still blank value.

-MP

[SanfordWhiteman]

I'd like to do some more VTL debugging in your instance at this point as it will be faster than the back-and-forth here. DM me if/when that's possible.