How do I modify the date format for a token using Velocity Script? | Community
Skip to main content
A
Anonymous
June 26, 2017
Solved

How do I modify the date format for a token using Velocity Script?

  • June 26, 2017
  • 1 reply
  • 7006 views

Hello Community,

We'd like to be able to change the date format for an expiration date token (see below) from appearing in an email as 2018-04-12 to April 12, 2018. How would I set up the Velocity Script to do so?

{{lead.Expiration Date:default=edit me}}

Thank you,

Laura Kimball

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by SanfordWhiteman
    #set( $dateOptions = {
      "formats" : {
        "userin" : "yyyy-MM-dd",
        "userout" : "MMMM d, yyyy"
      },
      "timezones" : {
        "userin" : "America/New_York",
        "userout" : "America/New_York"
      },
      "locale" : $date.getLocale()
    } )
    #set( $expirationDatelike = $lead.ExpirationDate )
    #set( $expirationDate = $convert.parseDate(
      $expirationDatelike,
      $dateOptions.formats.userin,
      $dateOptions.locale,
      $date.getTimeZone().getTimeZone($dateOptions.timezones.userin)
    ) )
    #set( $expirationDate_formatted = $date.format(
      $dateOptions.formats.userout,
      $expirationDate,
      $dateOptions.locale,
      $date.getTimeZone().getTimeZone($dateOptions.timezones.userout)
    ) )
    ${expirationDate_formatted}

    Note the very important inclusion of time zones (set the userin and userout time zone strings according to your tz).

    You'll see a lot of examples (frankly, any examples that weren't originally contributed by yours truly) that are broken because they are timezone-unaware.  Those examples may seem simpler, but they're broken.

    1 reply

    SanfordWhiteman
    SanfordWhitemanAccepted solution
    New Participant
    June 26, 2017
    #set( $dateOptions = {
      "formats" : {
        "userin" : "yyyy-MM-dd",
        "userout" : "MMMM d, yyyy"
      },
      "timezones" : {
        "userin" : "America/New_York",
        "userout" : "America/New_York"
      },
      "locale" : $date.getLocale()
    } )
    #set( $expirationDatelike = $lead.ExpirationDate )
    #set( $expirationDate = $convert.parseDate(
      $expirationDatelike,
      $dateOptions.formats.userin,
      $dateOptions.locale,
      $date.getTimeZone().getTimeZone($dateOptions.timezones.userin)
    ) )
    #set( $expirationDate_formatted = $date.format(
      $dateOptions.formats.userout,
      $expirationDate,
      $dateOptions.locale,
      $date.getTimeZone().getTimeZone($dateOptions.timezones.userout)
    ) )
    ${expirationDate_formatted}

    Note the very important inclusion of time zones (set the userin and userout time zone strings according to your tz).

    You'll see a lot of examples (frankly, any examples that weren't originally contributed by yours truly) that are broken because they are timezone-unaware.  Those examples may seem simpler, but they're broken.

    A
    Anonymous
    June 26, 2017

    AWESOME! Thank you so much Sanford!

    For a non-programmer like myself, do you have any suggestions for how to approach the development of these scripts? In other words, is there a "method to the madness"? For example, for the lead.DBCBalance script you helped me with earlier, the script was very simple--just 1 line, whereas with this particular script there are 25 lines of code...What is the difference?

    Thank you,

    Laura

    SanfordWhiteman
    SanfordWhiteman
    New Participant
    June 26, 2017

    Well, they're doing very different things, since the other one is just formatting an existing string and this one is actually creating Date objects from strings (which is a surprisingly sensitive process in any language) and then outputting them as strings.

    Because of the number/length of the function arguments, I broke up the parseDate() and format() calls into multiple lines with line breaks -- so each of those #set lines could technically be on one line, but then they'd be far harder to read.

    It's not really about lines of code (LoC), though. Yes, you do hear programmers bragging about their LoC (in both directions -- sometime we say, "I could do that in 3 lines" while in other contexts we say, "We have a mature codebase of 100,000 LoC, so don't tell us changes are simple.").

    But the key is writing the shortest amount of code that is readable and maintainable -- and no shorter! That means you add line breaks as necessary for readability, and declare variables (like my $dateOptions), instead of hard-coding values, for easier reconfiguration over time.  This may add lines but your code is better for it. Where you save "lines" is by using time-tested functions to do stuff, instead of trying to write your own. Like you don't try to write your own date parser when Velocity already has one that works.

    Overall, though, Velocity is a programming language, and I can't give non-programmer-y pointers for how to learn it. I love Velo (well, maybe that's strong, I enjoy learning its quirks and the power it brings to Marketo) but I am a programmer by trade, so...

    Terms & ConditionsAccessibility statement

    Loading footer...