Liquid data type updates

Question

Hi everyone,
With the next release (to go out on Monday) we're adding proper date format support in liquid for all modules. Besides all the improvements and additions made available with this release, one important note, which requires you to do some updates after the release, is that we're breaking backwards compatibility for liquid date tags by outputting the dates in ISO 8601 format ("yyyy-MM-ddTHH:mm:ss") instead of current format(“yyyy-MM-dd”).
Here is a brief overview of the changes:
All module fields which represent date or date times are now passed to Liquid as date time objects (previously they were passed as strings). This brings the following benefits:
Comparison between date time objects works correctly
It is possible to compute the difference between two date time objects using the minus filter. Example: {% assign dateDiff = Globals.Site.DateNow| minus: myDate %}
We added the means for obtaining the current date time: Globals.site.dateNow. The returned date is in the site’s time zone.
By default, when no filter is applied, all date variables will be output in the following ISO 8601 format: “yyyy-MM-ddTHH:mm:ss”. For example {{ myDate }} would output something similar to: “2014-12-12T07:19:49”. (Note: this is a backwards compatibility breaking change, as previously we outputted dates using the following format: “yyyy-MM-dd”. The breaking change only affects Liquid tags). Following the release, you should update your sites using the provided date filters to format the dates as you need.
The output of date time variables can be formatted using the following filters:
date (with no parameters)– displays a nice to read string representing just the date part from the date time variable. The date is formatted in the site’s culture. This compatible with the way older BC tags display dates. For example {{ myDate | date }}, in the English US culture will output a string similar to: “12-Dec-2014”.
datetime (new filter) – displays a nice to read string of the date time variable using the site’s culture. This compatible with the way older BC tags display date time. For example {{ myDate | datetime }}, in the English US culture will output a string similar to: “12-Dec-2014”.
date “format” (existing filter, nothing updated, mentioned here just for consistency) – displays the date in the site’s culture using a format specified by the format variable. The list with the available formats is available here: http://msdn.microsoft.com/en-us/library/8kb3ddd4%28v=vs.110%29.aspx. Note that the date filter can also be used to format objects that result as a difference between two date time objects, however, in this case the format string will respect a different set of rules as defined here: http://msdn.microsoft.com/en-us/library/ee372287%28v=vs.110%29.aspx. The following example demonstrates how to display just the number of days in the difference between two dates: {{ Globals.Site.DateNow| minus: myDate| date: "%d" }}
We added the Convert filter which can be used for converting variables to a certain type. The syntax is: variable | convert: “type”. Below are the values supported by the type parameter:
“date” – converts a variable to a date time instance. We only support the following formats for strings that are converted to date time: “yyyy-MM-ddTHH:mm:ss” and “yyyy-MM-dd”.
“number” – converts a variable to a number instance. If converting from string, only period “.” is supported as a decimal separator. This filter will probably be most useful when trying to convert GET query parameters: {% assign pageNumber = Globals.get.pageNumber | convert: “number” %}. The previous example assumes that URL that loaded the page contains a parameter named pageNumber. The convert numeric filter is an alternative to the rather hack-ish approach of converting to numbers using mathematical operators: {% assign myNumber = variable | plus: 0 }. Please note that it is not recommended to use the convert numeric filter just to assign numeric constants. For example, this approach is not recommended: {% assign myNumber = “3.14” | convert: “number” %}. Use the following approach instead: {% assign myNumber = 3.14 %} (note the lack of quotes around 3.14 in the second example).
“boolean” – converts a variable to a boolean instance. Please note, that just as it is the case with numerics, it is not recommended to use the “boolean” filter for declaring a boolean constant. For example this is not recommended: {% assign myBool = “false” | convert: “boolean” %}. Use the following syntax instead: {% assign myBool = false %}
“string” – converts a variable to its string representation.
We added implicit casting to the most relevant type in comparisons and inside filters representing mathematical operations (plus, minus, times, divide, modulo). With implicit casting, if one of the two operands is of type string and the other is of a different type (for example numeric or date time), we will attempt to convert the string operand to the type of the other. The conversion will fail if the string is not in an appropriate format for the type it is converted to (same rules as in the Convert filter are applied). In comparisons, if the implicit casting fails, the comparison is made with both operands converted to strings. Additional notes:
Implicit casting allows using date time literals directly in comparisons if the other operand is of date time type. For example, this will work correctly since "2015-01"15" will automatically be converted to date time before making the comparison: {% if myDate > "2015-01-15" %}Some message{% endif %}
Date parts obtained using the date filter can be used directly in comparisons with numerics. For example:
         {% assign daysDiff = Globals.Site.DateNow| minus: myDate| date: "%d" %}
          {% if daysDiff < 10 %}
            A message
          {% endif %}
With the implementation of implicit casting we also fixed some rather funny bugs related to comparisons and mathematical operations. For example, previously, 5 < 5.5 was evaluated as false, but 5.5 > 5 was evaluated as true. Also the result of 5| plus: 5.5 was 10, but the result of 5.5| plus: 5 was 10.5 (now 10.5 is the result of both operations, as expected).
As a potential caveat, note that implicit casting will bring the operands to the relevant type only if one of them is actually of that type. If both operands are of type string, the comparison is made as of between strings. This means that following condition is evaluated as false {% if "3" < "15" %}, because as a string "15" is smaller than "3".
Implicit casting from string to numeric only works if the string represents just a numeric. If the string contains additional characters, like a currency symbol, the conversion will fail. For example, this will not work correctly {% "$15" < 20 %}. Our goal, in the next releases, is to update all modules containing price related tags to have them in plain numeric format.
We added the following filters for easily formatting numeric values representing prices.
number - displays numbers with a fixed number of two decimals using the decimal separator appropriate to the site's culture. For example, in the English US culture, {{ 99| number }} will display 99.00
currency - displays numbers in the same way as number but also inserts the currency symbol at the beginning of the returned value. The currency symbol respects the site's culture. For example, in the English US culture, {{ 99| currency }} will display $99.00
In the next release or releases, we're going to focus on fixing the remaining data types for modules.
Cristinel

Answer 1

Liam, the server date isn't helpful for converting timezones. We would need a direct date filter. With a filter for UTC and one for the user we should be able to do quite a bit from there.
The most powerful things that could be implemented for date time are the following:
• moment.js and Moment Timezone built into the filters.
• the ability to add time info into date time fields
But I know that's a tall order.