Mastering Date Fields: Types, Formats, and Best Practices for Developers

Date Fields

In the realm of IT service management and application development, accurate and efficient handling of dates and times is paramount. Whether tracking the lifecycle of an IT ticket, scheduling maintenance, or auditing system activity, date fields are the bedrock of chronological data. In the context of BMC’s AR System (and by extension, its modern incarnation, BMC Helix ITSM), date and time values are not stored in a human-readable format like ‘2023-10-27 10:30:00’. Instead, they are meticulously translated into a numerical representation that allows for precise calculations and efficient storage. This article delves into the intricate workings of date fields in AR System, exploring their storage mechanism, the significance of core fields, and practical tips for managing them effectively.

How Time is Stored in AR System

At the heart of AR System’s date and time management lies a fundamental concept: the Unix epoch. AR System stores all date/time values as the integer number of seconds that have elapsed since 00:00:00 GMT on January 1, 1970. This point in time is often referred to as the “epoch time” or “Unix time.”

The Calculation: Imagine a calendar. AR System effectively counts every single day from January 1, 1970, up to the current date and time. This count includes all the leap years that have occurred within that period. Once the total number of days is determined, it’s converted into the equivalent number of seconds. This integer value is what’s ultimately stored in the database for any date/time field.

Why this approach? Storing dates as a numerical value representing seconds offers several advantages:

Precision: It allows for incredibly precise timestamps down to the second.
Comparisons: It makes comparing dates and times incredibly fast. A simple numerical comparison is all that’s needed to determine if one date is before or after another.
Calculations: Date arithmetic (e.g., calculating durations, adding/subtracting time) becomes straightforward mathematical operations on integers.
Standardization: It aligns with widely adopted computing standards like Unix time, fostering interoperability.

The Time Window: It’s important to note the supported range for these date/time values. AR System, using this integer representation, can store dates from January 1, 1970, through January 18, 2038. This 2038 cut-off is a well-known limitation in many systems that rely on 32-bit signed integers for time representation. For most practical IT service management scenarios, this range is more than sufficient.

The 9 Core Fields: The Backbone of a Request

In AR System, certain fields are fundamental to the lifecycle and management of almost every record, especially within modules like Incident Management, Change Management, and Service Request Management. These are often referred to as “core fields,” and among them, several are directly related to date and time tracking. Let’s explore these critical fields:

Here’s a breakdown of some of the most crucial core fields, with a focus on those related to time:

Request ID (Field 1): This is the unique identifier for a record. While not a date field, its creation time is implicitly linked to the system’s timestamping.
Submitter (Field 2): The user who initially created the record.
Create Date (Field 3): This is a vital date/time field. It captures the exact moment a record was submitted to the system. This value is stored as the number of seconds since the epoch, as described earlier. It’s a read-only field, automatically populated by the system upon record creation.
Assigned To (Field 4): The user or group currently responsible for the record.
Last Modified By (Field 5): The user who last made a modification to the record.
Modified Date (Field 6): Another critical date/time field. This field records the timestamp of the most recent modification made to the record. Like ‘Create Date’, it’s stored as seconds since the epoch and is automatically updated by the system whenever a change is saved.
Status (Field 7): Indicates the current state of the record (e.g., New, In Progress, Resolved, Closed). Changes to this field often trigger other system actions and are meticulously logged.
SD (Field 8): Often represents ‘Short Description’ or ‘Summary’, providing a brief overview of the record’s content.
Status History (Hidden) (Field 15): This is a special, often hidden field that acts as an audit trail for status changes. It’s particularly interesting because of how it stores its data.

Understanding the Diary Field Value in the Database

The ‘Status History’ field (Field 15) is a prime example of a ‘Diary’ field. Diary fields are designed to append information rather than overwrite it, providing a comprehensive history of interactions and status changes. When you modify a Diary field, the system doesn’t just update a single value. Instead, it appends a new entry to the existing data.

The format for an entry in a Diary field (like ‘Status History’) in the database typically looks like this:

[modified timestamp in seconds -| User -| Data]

Let’s break this down:

[modified timestamp in seconds]: This is the epoch time (number of seconds since Jan 1, 1970) indicating when this specific diary entry was created.
-| User -|: This acts as a delimiter and identifies the user who made the change or added the comment.
Data: This is the actual content of the diary entry – the new status, a comment, or any other relevant information.

Example: If a user changes the status from “New” to “In Progress” at a specific time, the diary field might store something like:

1678886400-|John Doe-|Status changed from New to In Progress.

This appended nature ensures that no historical information is lost, providing a rich audit trail for troubleshooting and analysis.

How to See the “Status History” (Field 15)

Accessing the ‘Status History’ can be invaluable for understanding the progression of a request. Here’s how you can view it:

Method 1: Via the View Menu (Remedy User Tool)

Open the form in question (e.g., an Incident ticket) in the Remedy User tool.
Ensure the form is in a viewable state, not necessarily modify.
Navigate to the View menu.
Click on Status History.

Method 2: Shortcut (Remedy User Tool – Modify State)

Open the form in question in the Remedy User tool, specifically in Modify state.
Once the form is loaded and in edit mode, press the keyboard shortcut Ctrl + H (or Control*H as some might refer to it).

Both methods will typically pop up a separate window or section displaying the historical entries for the status field, formatted with timestamps, users, and the associated data.

Customizing and Controlling Fields: Request ID Example

The ‘Request ID’ field (Field 1) is fundamental for identification. Administrators often need to customize its appearance and behavior, such as adding prefixes or restricting its length. This is done through the form and field properties.

Giving a Prefix to the Request ID Field and Restricting Length

To customize the ‘Request ID’ field:

1. Adding a Prefix (Default Value):

Open the AR System form in Developer Studio or the User Tool’s administration mode.
Locate the ‘Request ID’ field (Field ID 1).
Right-click on the field and select Properties.
Navigate to the Default Value section or tab.
Enter your desired prefix, for example, ABC.

Result: From this point forward, new ‘Request ID’s generated will automatically start with “ABC” (e.g., ABC0000000001).

2. Restricting Input Length:

With the ‘Request ID’ field’s properties still open, navigate to the Database tab or section.
Find the Input Length property.
Enter the maximum desired number of characters for the field. For instance, if your prefix is “ABC” and you want a total of 10 characters, you might set this to 10.

Result: Users will be prevented from entering more characters than the specified ‘Input Length’, ensuring data consistency.

Important Note: Modifying the ‘Request ID’ field’s properties, especially the input length or default value for existing records, requires careful planning and execution. It can impact existing data and workflows. Always test such changes in a non-production environment first.

Character Fields vs. Diary Fields: A Crucial Distinction

Understanding the difference between standard character (or text) fields and diary fields is vital for designing effective forms and managing data. The core difference lies in their data modification behavior:

Character Fields: These fields are designed for direct input and can be overwritten. When a user edits a character field, the old data is replaced with the new data. This is suitable for information that changes completely, like a name or a subject line.
Diary Fields: These fields are designed for appending information. As mentioned with ‘Status History’, when a diary field is modified, the new data is added to the end of the existing content, typically prefixed with a timestamp and the user’s name. This preserves a complete history of all entries, making them ideal for logs, notes, and audit trails.

Real-world Example:

A Character Field on a user profile might store their email address. If their email changes, you overwrite the old one with the new.
A Diary Field on a ticket might store all the communications and notes related to that ticket. Each new comment is appended, creating a chronological record of the ticket’s resolution journey.

Help Text: Guiding Your Users

Help text provides context and instructions for users interacting with your AR System forms. The way help text is displayed can vary based on the user’s login credentials, offering a layered approach to user assistance.

Help Text Behavior Based on User Type

When logged in as ‘Demo’ or a registered user with administrative privileges:

The system will display a comprehensive set of information for each field.
This typically includes:
- Field Name (Label Name): The user-friendly name of the field as it appears on the form.
- Field ID: The internal numerical identifier for the field.
- Help Text Value: The actual descriptive text you’ve configured for the field.

This detailed view is designed to aid administrators and power users in understanding the form’s structure and the purpose of each field.

When logged in as a standard or end-user (e.g., not ‘Demo’):

The system displays a more concise version of the help text.
It will primarily show:
- Just the Help Text Value: The descriptive text you’ve written to guide the user on how to fill out or interpret the field.
If there is no specific Help Text Value configured: The system will then fall back to displaying the field’s basic description, which might include its symbolic name, keyword information, or input length, depending on how the field was configured.

This tiered approach ensures that less technical users are presented with only the essential information they need, preventing them from being overwhelmed by technical details.

Troubleshooting Help Text Display Issues

Help text not appearing for any user:
- Verify that help text has been configured for the field in Developer Studio.
- Check form properties to ensure help text display is enabled.
- Ensure there are no conflicting active links or filters that might be suppressing help text.
Help text appearing too detailed for standard users:
- Confirm the user’s group or role. The system might be misinterpreting their privileges.
- Review the help text configuration for the specific field to ensure it’s not inadvertently set to display administrative details.
Field ID or Label Name showing unexpectedly for standard users:
- This usually indicates that either no help text value is configured, or there’s an issue with how the system is falling back to field descriptions. Re-evaluate the help text content for that field.

Interview Relevance

Understanding how date fields work in AR System is a common topic in interviews for roles involving AR System administration, development, or ITSM support. Here are some questions you might encounter:

“Can you explain how AR System stores date and time values?”
“What is the significance of the ‘epoch time’ or ‘Unix time’ in AR System?”
“Describe the purpose of the ‘Create Date’ and ‘Modified Date’ fields.”
“How does a Diary field differ from a standard character field? Give an example.”
“Explain the ‘Status History’ field and its data storage format.”
“What is the time range limitation for AR System date fields?”
“How would you add a prefix to the ‘Request ID’ field?”
“Imagine a user reports that their help text is not displaying correctly. What troubleshooting steps would you take?”

Being able to articulate the concepts discussed in this article will demonstrate your technical understanding and practical experience with AR System.