ServiceNow Date Manipulation: Adding 14 Days to the Current Date with GlideDateTime

Date manipulation is a common requirement in ServiceNow development – from setting due dates and reminders to scheduling future tasks. Being able to calculate dates (for example, adding two weeks to the current date) is essential for automating workflows and ensuring timely actions. However, working with dates and times in ServiceNow can be tricky. Developers often face challenges such as handling different time zones, using the appropriate APIs in client vs. server scripts, and understanding how ServiceNow stores and displays date/time values.

In this article, we will explain how to add 14 days to the current date in ServiceNow using the GlideDateTime API. We’ll discuss how GlideDateTime works, demonstrate the correct use of the addDays() function, and address common pitfalls (like time zone issues and client-side limitations). By the end, you’ll have a clear, step-by-step understanding of ServiceNow date manipulation and best practices for accurate date calculations.

Understanding the GlideDateTime Class in ServiceNow

ServiceNow provides the GlideDateTime class (server-side) to handle date and time values, making it easier to perform date calculations. A GlideDateTime object contains both date and time information, and under the hood it stores the value in UTC (Coordinated Universal Time). When you create a new GlideDateTime without any parameters, it is initialized to the current date and time of the system (usually the instance's server time, which is often UTC by default). This means new GlideDateTime() effectively gives you “now” in terms of the system time.

Some key points about GlideDateTime:

• It provides various methods to manipulate dates and times, such as addDays(), addMonths(), addYears(), as well as methods to get parts of the date/time or format the output.

• ServiceNow also has related classes like GlideDate (which only keeps the date part) and GlideTime (for time of day), but GlideDateTime is most commonly used when adding or subtracting days since it handles full date-time stamps.

• GlideDateTime automatically handles conversion between system time and user display time. For example, if a user in a different time zone views a GlideDateTime value, ServiceNow will convert it to that user’s time zone for display. (We’ll cover time zone issues in detail later.)

• Important: GlideDateTime is a server-side API. You can use it in business rules, script includes, background scripts, etc. It is not available in client-side scripts or on the Service Portal. If you need to manipulate dates in a client script, you must use a different approach (such as the JavaScript Date object or a GlideAjax call, discussed below).

Understanding these basics of GlideDateTime will help you avoid mistakes and use it effectively for date calculations in ServiceNow.

Common Challenges with Using addDays() in ServiceNow

When adding 14 days to the current date (or performing similar date math), developers have encountered a few common issues. Let’s highlight these pitfalls and clarify how to address them:

• Time Zone Confusion: Because new GlideDateTime() uses the system's time (typically UTC), the resulting date can appear off by several hours or even shift by a day when viewed in a different time zone. In other words, you might correctly add 14 days in GMT, but if your user profile is in a timezone behind GMT, the date might display as 13 days ahead instead of 14 due to the conversion. For example, one user found that the script was technically adding 14 days, but the output looked like the wrong date because it was being converted back to their local time zone which was behind the system time. This can be confusing if you don’t realize the effect of time zones on date display.

• Misusing the return value of addDays(): The addDays() function (and similar methods like addDaysUTC() or addDaysLocalTime()) does not return the new date – it updates the existing GlideDateTime object in place. This is a crucial point: if you do var newDate = gdt.addDays(14); // incorrect code you will not get the intended result in newDate. In fact, newDate would end up being undefined because addDays() returns nothing. The correct usage is to call gdt.addDays(14) on your GlideDateTime variable, and then use the same object (gdt) to get the new value. Many developers mistake this and try to assign the function call to a variable or field, which leads to incorrect or null values. Always remember that addDays changes the GlideDateTime object but doesn’t give a value back.

• Client-Side Usage of GlideDateTime: As mentioned, GlideDateTime is not available in client-side scripts. If you attempt to use new GlideDateTime() or gdt.addDays() in a client script (like an onChange or onLoad client script), you’ll get an error such as “GlideDateTime is not defined”. This is a common hurdle – for example, a developer tried to use GlideDateTime in an onChange client script to add 10 days to a date field and encountered this error. The solution in such cases is to use an alternative approach (such as the JavaScript Date object on the client) or perform the calculation on the server via GlideAjax. We will discuss this alternative soon, but the key point is: use GlideDateTime only in server-side code (Business Rules, Script Includes, Flow actions, etc.).

• Using the Wrong Method or Class: Ensure you are using the correct method for your object. For instance, there is an addDaysLocalTime() method that adds days relative to a GlideDateTime’s local time zone context, and a corresponding addDaysUTC(). Some might also come across a method like addWeeks() – note that addWeeks() exists for GlideDate (date-only) objects, but not for GlideDateTime. If you tried gdt.addWeeks(2) on a GlideDateTime, it wouldn’t work (or would require a different approach). The safest route for weeks is simply to use addDays(14) for two weeks. Stick to the GlideDateTime methods as documented.

By keeping these challenges in mind, you can avoid common mistakes when calculating dates. Next, we’ll walk through the correct way to add 14 days to the current date step by step.

Step-by-Step: How to Add 14 Days to the Current Date

Let’s go through a simple guide to add 14 days to “today’s date” in ServiceNow using GlideDateTime. This example assumes we are writing server-side code (for example, in a Business Rule or a server script):

1. Initialize the current date/time: Create a GlideDateTime object for the current moment. This is as easy as:

   var gdt = new GlideDateTime();

   At this point, gdt holds the current date and time (system timezone). For example, if today is March 1, 2025 10:00:00 GMT, then gdt represents that date/time.

2. Add 14 days to the date: Use the addDays() method on the GlideDateTime object:

   gdt.addDays(14);

   This will push the date contained in gdt forward by 14 days. If gdt was March 1, 2025 10:00:00 GMT, it now becomes March 15, 2025 10:00:00 GMT. The object is modified in place. (Remember, addDays() doesn’t return a value – it just alters gdt. So we don’t assign the result to a new variable; we continue to use gdt itself.)

3. Retrieve or use the new date: Now gdt represents the date 14 days in the future. You can use this new value in several ways:

   • If you want to set a field on a record (say, a Due Date field on the current record in a Business Rule), you can do:

     current.due_date = gdt.getValue();

     Here, gdt.getValue() gives the date-time in the internal format (UTC, in yyyy-MM-dd HH:mm:ss format). We assign that to the record’s due_date field. Using getValue() is recommended for setting date/time fields. (Directly assigning the GlideDateTime object gdt might also work, but assigning the string value ensures clarity.) This step is crucial because, as noted, doing something like current.due_date = gdt.addDays(14) would not work – addDays(14) returns nothing, so you must call it first, then set the field with the updated object.

   • If you just want to output or log the new date (for example, in a script or for debugging), you can use gs.info() or gs.print(). It’s often useful to get the date in the user’s readable format. You can do:

     gs.info("New date (14 days from now): " + gdt.getDisplayValue());

     getDisplayValue() will return the date/time as a string formatted in the current user’s time zone and date format. This is helpful to double-check that the date is what you expect a user to see (e.g., it might print “March 15, 2025 2:00:00 PM” if that’s the user’s local time for the GMT value). If you use gs.info(gdt) directly, it will print the internal value (which could be in UTC). So using getDisplayValue() makes the output more intuitive.

   • Another method, if you need just the date portion (no time), could be gdt.getLocalDate(), which gives the date in the user’s time zone. However, for most cases getDisplayValue() or getValue() will suffice depending on whether you need a user-friendly string or a machine-friendly string.

4. (Optional) Verify the result: It’s good practice to verify that your calculation is correct, especially if time zones are involved. If you run this code in a scoped app or as a background script, you can print both the value and display value:

   gs.info("New date (sys): " + gdt.getValue()); gs.info("New date (user): " + gdt.getDisplayValue());

   Ensure that the date is exactly 14 days later. If today was 2025-03-01, the new date should be 2025-03-15 (same time of day). This confirmation step can help catch any off-by-one issues.

   
   

Following these steps will reliably add 14 days to the current date in ServiceNow. For instance, using the above in a Business Rule after inserting a task could automatically set its due date two weeks out. The core idea is straightforward: get “now”, add 14 days, and then use the updated date.

Handling Time Zone Considerations

Time zones can be a source of confusion in date calculations. ServiceNow stores date/time values in UTC, but displays them in the user's local time zone (as per their user profile settings). This means that if your instance is set to GMT and a user is in GMT-5 (for example, EST), what’s “March 15, 10:00 UTC” will show up as “March 15, 5:00 AM” for that user (which is still March 15, but time-adjusted). However, issues arise particularly around the boundaries of days.

Consider this scenario: a user is in a Pacific Time zone (behind GMT). If the current time is near the end of the day in GMT, adding 14 days in GMT might push the date to the next day for the user. In one community example, a script added 14 days and got the correct result in GMT, but when converted to the user’s time zone, it appeared as the previous day. Essentially, the calculation was right, but because the user’s local time was behind, the displayed date looked off by one.

To handle such situations, keep these tips in mind:

• Always use getDisplayValue() for user-facing output. If you want to show the date or use it in a message, getDisplayValue() will ensure you’re seeing the value in the user’s time zone. This helps confirm that “14 days from now” truly looks like 14 days ahead on the calendar for the user. In our example, using gdt.getDisplayValue() after gdt.addDays(14) would show the expected local date. If it shows one day less, that signals a time zone conversion issue in how the calculation was done.

• Use addDaysLocalTime() if needed. The GlideDateTime API provides an addDaysLocalTime(int days) method. This method adds days based on the local time rather than absolute time. For most scenarios, addDays() is sufficient, but addDaysLocalTime() can be useful if you want to ensure the date moves by whole days in the context of a specific time zone. For example, if it’s 11:00 PM on Jan 1 and you add 1 local day, addDaysLocalTime(1) would give Jan 2, 11:00 PM in the same local zone (whereas a normal addDays(1) adds 24 hours, which might roll into Jan 2 or Jan 3 depending on UTC offset). In practice, if you encounter the off-by-one issue, using addDaysLocalTime(14) instead of addDays(14) could resolve it by anchoring the addition to the local date. Just remember that this still modifies the GlideDateTime object in place without returning a value (just like addDays) – use it the same way (call it, then get the value) and not as an assignment.

• Be mindful of Daylight Savings Time (DST): If the 14-day addition spans a daylight savings transition (spring or fall time change), the exact hour of the result might shift by an hour. GlideDateTime will handle the time zone conversion for you, but be aware that “14 days from now” might end up 13 days and 23 hours in terms of absolute hours if a DST jump occurs. Usually this is not a big issue, but it’s something to note for precise scheduling. Using local time addition helps ensure the result is the same local clock time on that future date, DST considered.

• System time vs. User time: If you need to ensure the calculation starts from the user’s current date (not the system’s), you could initialize the GlideDateTime with the user's time. One way to do that is by using the user’s time zone offset. However, the simpler approach is: do the calculation in UTC (which is what ServiceNow will do by default), then use getDisplayValue() for the user. In most cases, this yields the correct local date. The difference is only noticeable if the exact hour matters or if you are doing something like setting a date at midnight. For example, if you want exactly “14 days from today at 00:00 hours”, you might create a GlideDateTime for today’s date at midnight local, then add 14 days, rather than starting from now.

In summary, to avoid time zone headaches, test your date calculation with users in different time zones if possible. Print both the getValue() (system) and getDisplayValue() (user) to see how it behaves. Usually, sticking to addDays() and then using the display value is enough. But if you find the result is a day off in display, consider switching to addDaysLocalTime() for that use case. The goal is to ensure that adding 14 days means the same thing in whichever context you need it.

Alternative Solutions for Client-Side and Other Scenarios

What if you need to add 14 days to a date on the client side (for example, in a form client script or in the Service Portal)? Since we cannot use GlideDateTime directly in client scripts, here are some alternative approaches:

• Use the JavaScript Date object (client-side): In client scripting, JavaScript’s native Date object can be used to manipulate dates. The logic is similar: get today’s date, add 14 days, then set the value back to a form field. For instance, in a client script you might do:

  var date = new Date(); // current date/time (client's local time) date.setDate(date.getDate() + 14); // add 14 days var newDateStr = formatDate(date); // Format the date to YYYY-MM-DD hh:mm:ss (if setting a DateTime field) g_form.setValue('your_date_field', newDateStr); // you'll need to format the date as a string that ServiceNow accepts

  In the above, formatDate() would be a function you write to convert the JavaScript Date into the proper string format (e.g., "2025-03-15 10:00:00"). The concept was demonstrated in a Stack Overflow answer: GlideDateTime is not available on the client, so you use the Date object, then g_form.setValue() with the formatted date. Keep in mind formatting can be tricky (especially with time); ensure the string matches the expected format or use a simpler approach like setting just the date component if it’s a date-only field.

• Use GlideAjax to call a server script: If formatting the date on the client is too cumbersome or if you want to reuse server logic, you can use GlideAjax. With GlideAjax, you can call a Script Include (server-side) from a client script. The Script Include can perform the GlideDateTime calculation (add 14 days) and return the result. The client script then receives the date (as a string) and can set it to the field. This approach offloads the calculation to the server (where GlideDateTime is available) and is especially useful for complex calculations or if you want to maintain consistent logic between client and server.

• Workflow/Flow Designer: If you prefer not to script at all, ServiceNow’s Flow Designer or Legacy Workflow can also handle date calculations. For example, in Flow Designer you might use the Set Field value action to set a date field to "Today plus 14 days" by using a calculated value. Or you could use a scheduled trigger. While this veers away from scripting, it’s good to know that for many standard use cases (like setting due dates or reminder dates) you might achieve it with configuration. The downside is less flexibility compared to scripting, but it's an alternative for those who want a no-code solution.

Each of these alternatives ensures that you can add 14 days to a date in contexts where GlideDateTime isn’t directly available or ideal. The JavaScript Date approach is straightforward for client side, while GlideAjax provides a bridge to server-side power from the client. Always choose the method that best fits where your code is running and who it’s for (user's browser vs. server).

Examples and Use Cases

To make the discussion more concrete, here are a few practical examples of how adding 14 days to the current date can be applied in real ServiceNow scenarios:

• Automating Due Dates: Imagine you want every new incident or task to have a due date two weeks from its creation. You can implement a Business Rule (after Insert) that takes the current date/time when the record is created and adds 14 days to set the due_date field. This ensures a default follow-up timeline. For instance, if an incident is opened on March 1, the due date would auto-fill to March 15. This can help in SLA tracking or reminding assignees to resolve the issue within two weeks.

• Reminder or Review Dates: Suppose you have a custom application where a record (say, a contract or a knowledge article) needs a follow-up or review after 14 days. You can use a script to calculate the review_date = today + 14 days when the record is updated or approved. This way, a notification can be triggered on that review_date to remind the relevant person. It's a simple calculation that automates a future reminder.

• Temporary Access Expiration: In an ITSM or security context, you might grant someone temporary access or a role for 14 days. Using a script, you could set an expiration date field to now + 14 days. This could later be checked by a scheduled job to revoke access when the date is reached. Automating the expiration upon creation saves manual calculation and entry errors.

• Maintenance Window Planning: If you are scheduling a change request and you want to automatically suggest a window two weeks out, you could have a UI action or script that computes the date 14 days from today as a starting point for the planned end date. This gives the user a quick option like “set planned date to two weeks from now” for convenience.

• Service Catalog Requests: In a catalog item form, suppose there's a date field that should default to two weeks in the future (maybe a “needed by” date default). You can use a client script on load to populate that field with today + 14 days. Here you’d use the client-side approach (JavaScript Date or GlideAjax) since it’s running in the catalog item form on the client.

These examples show how versatile adding a fixed offset to the current date can be, spanning ITSM, security, and custom app use cases. In each scenario, the goal is to automate date calculations to enforce consistency and save time. By using the techniques discussed (and being wary of pitfalls), implementing such use cases becomes much easier.

Conclusion

Working with dates and times in ServiceNow requires an understanding of the platform’s APIs and how time zones affect data. In this article, we learned that the GlideDateTime class is a powerful tool for ServiceNow date manipulation, providing the addDays() function to easily add (or subtract) days. To add 14 days to the current date, we simply create a GlideDateTime for now, call addDays(14), and then use the updated object (e.g., setting a field or getting the display value).

Along the way, we highlighted some best practices and lessons:

• Always consider the context (server vs. client). Use GlideDateTime on the server, and alternate methods like JavaScript’s Date on the client.

• Remember that addDays() (and similar methods) modify the object in place and do not return a value. Use getValue() or getDisplayValue() after manipulation to retrieve the result.

• Keep an eye on time zone differences. ServiceNow will handle conversion for you, but the apparent date might shift if you’re not careful. Use getDisplayValue() to check what a user will actually see, and use addDaysLocalTime() when you need to anchor calculations to local time to avoid off-by-one-day issues.

• Test your logic with different scenarios (different time zones, crossing month boundaries, etc.) to ensure it works as expected in all cases.

By following these practices, you can reliably perform date calculations like adding 14 days, 30 days, or any interval to dates in ServiceNow. This enables you to automate and enforce business rules around scheduling and deadlines with confidence.

Next Steps: If you’re a developer, try writing a simple Business Rule or background script that uses GlideDateTime to add days to a date, and observe the output. Check the ServiceNow documentation for other useful date methods (such as dateDiff, addMonths, or methods to get the day of week) to further enhance your date handling logic. With a solid grasp of GlideDateTime, you’ll be well-equipped to handle all sorts of date manipulations in ServiceNow, making your applications more dynamic and time-aware.