Many sites require that a different date format be used by Service Desk other than the default US format provided.

This document describes how to change these settings to suit international sites. For example to use the format DD/MM/YYYY.

As well as how to set different date formats for users connected to different secondary web servers.

Following the steps here will also address an issue where the "am" and "pm" flags in the Activity Log appear to be randomly assigned, which can result from an incorrect use of syntax in the DateFormat variable.

Release: 12.6 or higher
Component:  CA Service Desk Manager

There are two key variables for setting the Date Format at a server level.

The web.cfg variable "DateFormat" affects the Web Client and provides different date formats. The default date format is "MM/DD/YYYY hh:mm a(am,pm)." The syntax is described in the Administration Guide. It is also repeated in the web.cfg file itself (web.cfg is found under NX_ROOT\bopcfg\www folder).

If you have multiple web engines defined in one Service Desk server, then the DateFormat statement in each *web*.cfg file should be modified. For example, you may need to modify primary-web2.cfg and primary-web3.cfg in addition to web.cfg.

The NX.env variable "NX_EXPANDER_FORMAT" affects outgoing Notifications. 

These variables only change the display of date type fields in Service Desk. They have no impact on dates stored as strings, such as may be typed by a user into a Comment or Description field.

The underlying data is stored in a standard time format in the database, which is unaffected by these variables. Thus, secondary servers may be configured with different date format settings without any impact on what other servers are seeing or the integrity of the data.

These variables are applicable to all releases of Service Desk.

It is recommended that you update both DateFormat and NX_EXPANDER_FORMAT at the same time so that the formats are consistent.

Warning: These changes update Service Desk files. Please back them up before attempting this procedure.

DateFormat for Service Desk Web Client Dates

The Service Desk Administration Guide contains the syntax for setting the DateFormat command in the NX_ROOT/bopcfg/www/web.cfg file so that most dates within the Service Desk web client, such as the Activity Log dates, are in the correct format.

Here is the description from the web.cfg file which includes the example of changing from the default US date format to an English format:

# DateFormat specifies the order of data elements in the display.
# Rearrange MM (month), DD (day), YYYY (year), hh (hour), mm (minutes),
# and a(am, pm) (AM/PM suffix) as required.
# 
# M - print 1 or 2 digits of month.
# MM - print 2 digits of month.
# D - print 1 or 2 digits of date.
# DD - print 2 digits of date.
# YY - print 2 digits of year
# YYYY - print 4 digits of year.
# H - print 1 or 2 digits of hours on 24 hour clock
# HH - print 2 digits of hours on 24 hour clock
# h - print 1 or 2 digits of hours on 12 hour clock
# hh - print 2 digits of hours on 12 hour clock
# m - print 1 or 2 digits of minutes
# mm - print 2 digits of minutes
# s - print 1 or 2 digits of seconds
# ss - print 2 digits of seconds
# a(am,pm) - print am and pm as a string
   
# Change date format from "MM/DD/YYYY hh:mm a(am,pm)" to "DD/MM/YYYY hh:mm a(am,pm)".
# John Smith (ABC Ltd). 25/05/2009. Change request: ABC5678.
DateFormat DD/MM/YYYY hh:mm a(am,pm)

DateFormatNoTime

The variable "DateFormatNoTime" has been removed from Service Desk r11.0 and up. The description remains in the Service Desk Administration Guides for r11.x and r12.x, but the code line functionality has been removed. This product documentation will be updated for future releases. The variable is applicable to Service Desk 6.0 SP1 and below. However, CA Support recommends discontinuing use of this deprecated variable in order to avoid requiring to do so upon upgrade. There are no known problems if this variable is left in place in the web.cfg, however, as it has no code line functionality to execute, it will be ignored.

12 Hour vs. 24 Hour Time

Capital letters denote 24 hour time and lower case 12 hour time.

Recycle of Service Desk is Required:

Changes to the web.cfg file will not be effective until Service Desk is recycled. A recycle is also required if updating the EXPANDER_FORMAT (below), and both changes may be done at once.

Update of the web.cfg.tpl file

Changes made to the web.cfg must also be repeated in the web.cfg.tpl file in order to avoid being overwritten when a pdm_configure is run.

Format Order

The "DateFormat" specifies the order of data elements in the display. Rearrange MM (month), DD (day), YYYY (year), hh (hour), mm (minutes), and a(am, pm) (AM/PM suffix) as required.

Further Examples

To use a European date format, uncomment the line and change the format to:
DateFormat DD/MM/YYYY hh:mm a(am, pm)
 
To show the time using a 24-hour clock, uncomment the line and use the format:
DateFormat MM/DD/YYYY HH:mm
 
Combinations are also permitted To have the date in European format and the time in 24-hour clock format, use:
DateFormat DD/MM/YYYY HH:mm

Different date and time formats on secondary servers

Each secondary server has its own web.cfg and NX.env files. These files only affect the display of the date format. They do not affect the underlying date information stored in the database, which is stored in a standard time format of seconds from January 1st 1970. Therefore different secondary servers may have different data formats, which is useful for users connecting to secondary servers in different time zones.

The web.cfg can be configured with different date and time formats for multiple secondary servers.

When adding a webengine on secondary servers, pdm_edit.pl utility creates a new web.cfg file for each webengine on secondary server. The files can be independently modified and used to alter the features of webengine. Each secondary server can have a different date and time format. Be sure to follow the format specified and remove the comment character '!' from the web.cfg DateFormat variable.

Any changes to these files will require a recycle of Service Desk services on all servers to go into effect.

Also review the NX.ENV file if using the EXPANDER_FORMAT option.

EXPANDER_FORMAT for Notifications

The NX.env file variable EXPANDER_FORMAT is used for the display of dates of Notifications. The default date format is mm/dd/yyyy as shown in this example of an Initial Notification:

         Incident XX Initial.
         Assigned to: [EXAMPLE USER]
         Customer: [EXAMPLE USER]
         Description: This is an email notification which contains as date field.
         Open Date: 05/20/2019 08:38:55

The EXPANDER_FORMAT is used to change this format. This is updated from a command line utility. It is not available as an option in Options Manager, as it is not stored here but instead is a variable only in the NX.ENV file.

As an example assume a format of yyyy/mm/dd is required, then run the following commands:

pdm_options_mgr -s EXPANDER_FORMAT -v yyyy/mm/dd -a pdm_option.inst
pdm_options_mgr -t EXPANDER_FORMAT -v yyyy/mm/dd -a pdm_option.inst

Note: A recycle of the Service Desk service is required.

You may make these changes to the NX.ENV and to the .tpl file manually. However, this process is recommended as it updates both files in one action, and is less prone to accidental error.

   Incident 87 Initial.
   Assigned to: [EXAMPLE USER]
   Customer: [EXAMPLE USER]
   Description: This is an email notification which contains a new date field order.
   Open Date: 2019/05/20 08:45:47

There will now be a new variable for the EXPANDER_FORMAT in the NX.env file.

This is how the NX.env line would look if a European date format was created with the above process:

@NX_EXPANDER_FORMAT=DD/MM/YYYY HH:mm:ss

Display and Log Entries of pdm_options_mgr (Optional)

It is typically not required to review the logs for these changes. They are well understood and there are no known problems.

The manual changes made to the web.cfg file will not be recorded in the Service Desk logs.

The changes made via pdm_options_mgr will however make log entries. For the record, the onscreen display of a successful update will look like this:

C:\>pdm_options_mgr -s EXPANDER_FORMAT -v yyyy/mm/dd -a pdm_option.inst
C:\>pdm_options_mgr -t EXPANDER_FORMAT -v yyyy/mm/dd -a pdm_option.inst
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
        1 file(s) copied.
C:\>

The log file entries will look like this. For the first command:

[EXAMPLE SERVER] options_mgr 6100 SIGNIFICANT options_mgr.c 1733 NX_INSTALL sym: EXPANDER_FORMAT val: yyyy/mm/dd

For the second command:

[EXAMPLE SERVER] sql_agent          6248 SIGNIFICANT  sql_agent.c     238 STARTUP of sql_agent:mdb:rgen-#4516:

[EXAMPLE SERVER] sql_agent          6248 SIGNIFICANT  sql_agent.c     278 SHUTDOWN of sql_agent:mdb:rgen-#4516:

[EXAMPLE SERVER] options_mgr        6296 SIGNIFICANT  options_mgr.c   1733 NX_INSTALL sym: busy_agent_threshold val: 70

[EXAMPLE SERVER] options_mgr        2232 SIGNIFICANT  options_mgr.c   1733 NX_INSTALL sym: default_schedule val: 4601

[EXAMPLE SERVER] options_mgr        7900 SIGNIFICANT  options_mgr.c   1733 NX_INSTALL sym: rule_archive_path val: C:/PROGRA~1/CA/SERVIC~1/site/data/archive

[EXAMPLE SERVER] options_mgr        3868 SIGNIFICANT  options_mgr.c   1733 NX_INSTALL sym: rule_history_length val: 50

[EXAMPLE SERVER] options_mgr        3940 SIGNIFICANT  options_mgr.c   1733 NX_INSTALL sym: allow_exceed val: Yes