Labels

accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Saturday 20 February 2010

Comparing Dates and Time Zones

Date and time calculations are a bit tricky in UCM. Unlike regular numbers, dates and times cannot be calculated or compared to one another directly.

Comparing numbers is easy, consider this example:
<$if 6 gt 5$>
This code is always true!
<$endif$>
Dates and times cannot be compared this way unless they are converted to numbers, using toInteger(). Unfortunately there is no way to turn that number back into a date, so it's not too useful. A better way to manipulate timestamps without converting them is to simply "parse" them, using the parseDate() function.
<$myBirthday = "5/3/77"$>
<$if parseDate(myBirthday) gt parseDate("18/09/1970")$>
I was born after Hendrix died, on <$myBirthday$>!
<$endif$>
Parsing a date depends on the format of the timestamp. There are many different formats for timestamps so you'll need to figure out which ones are used by your UCM installation. The system locale decides how to format and recognise timestamps. For example, the UK locale uses dates in d/M/yy format, whereas the US locale is M/d/y. The system locale and timezone are chosen when UCM is first installed. Users can choose to use their own locale and change the way dates and languages are displayed just for them. UCM will recalculate timestamps and present the correct timezone for the user's locale whenever they look at a date, but continue to store dates according to the system locale. Any dates that are entered need to follow the (user) locale's recognised date formats, which may or may not include seconds, military hours and so on. The system locale can be changed on reboot using the SystemProperties utility; the user local is easily switched from the Content Server "My Profile" page.

Apart from simple date/time comparisions, UCM can also do a great job at converting a given timestamp to the current timezone, adding daylight saving as required for us. You will need to tell it what timezone you are converting from by manually adding the timezone and then explaining the format of the timestamp. Use zz to indicate a timezone code. For example, let's convert the new year's countdown in New York to my local time (Sydney) and see when they'll join in on our party.
<$parseDateWithPattern("1/1/11 America/New_York",
"d/M/y zz")$>
Unfortunately there doesn't seem to be a built-in way of converting the local timestamp to a specified timezone. I get around this by calculating the difference between a date in local time and the same date specified as another timezone, then adding that difference to my local time. For example, when we're doing the new year's countdown in Australia, how far behind will the UK be?
<$newYearUK = parseDate("1/1/2011")
+ toInteger(parseDate("1/1/2011"))
- toInteger(parseDateWithPattern("1/1/2011 Europe/London",
"d/M/yy zz"))$>
One of the quirks I've observed with handling date objects is that errors are not reported in the server output log. Your code simply keeps going like nothing happened! This makes problems difficult to trace and you'll get unexpected results. It's a good idea to print out your timestamps as you manipulate them so you can see where any problems are.

**** UPDATE ****
Alec Kloss sent me an email with the following tip:
"...you should be able to go to any Content Server generated page and append
&UserTimeZone=America/Chicago
to the end of the URL and... that will change the timezone of all displayed times accordingly."
Nice one!

2 comments:

  1. If you have a date in CET
    01.01.12 00:00 CET
    when I do this in a rule
    <$dprDerivedValue=formatDateWithPattern(#active.xIssueDate,"yyyy-MM")$>
    to get 2012-01
    I actually get 2011-12!
    The date used is a GMT: 2011-12-365 23:00 GMT
    When I do
    <$UserTimeZone="Europe/Berlin"$>
    beforehand, the
    <$xComments = formatDateWithPattern(#active.xIssueDate,"yyyy-MM-dd HH:mm zz")$>
    provides the pattern
    2012-01-01 00:02 CET
    But when trying only
    yyyy-MM
    I still get the 2011-12
    Ugly and I do not want to remove the CET from the date string afterwards - not good approach.
    Any clue?

    thanks

    ReplyDelete
    Replies
    1. It should work fine when the UserTimeZone is specified and the formatDateWithPattern just uses yyyy-MM. If you can't get it to behave, just do a regexReplaceAll on the timestamp to remove the timezone.

      Delete