# How to interpret the Hexadecimal values in a Time/Date value

## Abstract

The hexadecimal format for a time/date value in Notes is an easier way to read what is actually a 64-bit binary value which contains all the information necessary for storing and converting times and dates. Each of the binary digits of this value are either a flag, a time zone, a date, or a time.

## Content

Notes often displays time/date values in a 16-digit hexadecimal number format. Replica IDs, Sequence Dates, and UNIDs are all examples of this. This document explains how these hexadecimal values can be converted into dates, times, time zones, and daylight savings properties.

The hexadecimal format for a time/date value in Notes is an easier way to read what is actually a 64-bit binary value which contains all the information necessary for storing and converting times and dates. Each of the binary digits of this value are either a flag, a time zone, a date, or a time.

For example, a Replica ID is actually a representation of the creation time of a database:

10000101001001010110010001101000:00000000011001110010010011010100

All but the first two hexadecimal digits in a Replica ID are the date and time of the creation date of the database. The rightmost eight digits are the number of 100ths of a second since 12:00 AM Greenwich Mean Time (GMT) of the particular day. This is true regardless of the time zone in which the database was created because Notes stores all time values in GMT as a universal time standard. Working towards the left, the next six digits of the replica ID are a whole number of days, indicating the creation day (in Greenwich Mean Time) that the database was created. Because 256468 represents 03/28/1997, the image above shows that the database properties are for a replica of the original database. This number is actually the date in its Julian notation See the technote, "Error: 'Unable to interpret time or date' when entering specific dates from the year 1752" (#1098816) for more information. Following the steps outlined below to convert a hexadecimal value into a standard time value, the eight digits of the time portion of the value represent 67596.36 seconds since midnight GMT or 06:46:36.36 PM, but the time zone is stored elsewhere.

The leftmost two digits of the hexadecimal value store the time zone and daylight savings information for the time/date value. Remembering that the real value is a binary number, one can see that these eight bits of the value work as a set of numbers to indicate the offset from GMT as well as a bitmap to flag both the time zone and whether the value should be converted for daylight savings.

From the example, the replica ID stores this information as 85, which is 10000101 in binary. This binary number can be broken into two bitmaps, a 2-bit number, and a 4-bit number. The first bitmap indicates whether the value should be converted for daylight savings, while the second bitmap indicates whether the time zone is in the eastern or western hemisphere. The 4-bit number is the number of whole hours from GMT the time zone is offset. The example is a database created in the US Eastern time zone (5 hours west of GMT) on a server which obeys daylight savings.

 Value DST E/W :30 :15 1:00 85 1 0 0 0 0 1 0 1

Notes will then read this value as being five hours west of Greenwich, and as observing daylight savings. Further, 86 represents US Central Time (six hours west of Greenwich), 87 represents US Mountain Time, and so on. Because of the DST flag, each of these examples would be converted for daylight savings depending on both the date part of the time/date value and the DSTLaw parameter on the client. If the time/date value does not observe daylight savings, the same time zones mentioned above will be represented by 05, 06, and 07, respectively. In other words, the DST flag will not change as the year progresses. Even in December, databases created in the Eastern time zone should continue have replica IDs that start with 85. This way, Notes will properly convert times for dates or zones that observe different daylight savings rules (e.g. Europe and the United Sates, Arizona and California, or Northern and Southern hemispheres). The Notes client and the Domino server use the DSTLaw parameter in the INI file to control the daylight savings rules during the year. Changing this parameter may change the way in which time/date values are displayed, but will not change the underlying stored value.

For time zones which are offset a fraction of an hour from GMT, Notes adds 15 minute increments to the whole hour offset. Thus, databases created in Newfoundland will show A3xxxxxx:xxxxxxxx because this time zone is three and a half hours west of GMT.

 Value DST E/W :30 :15 Offset A3 1 0 1 0 0 0 1 1

The following table lists all the time zones used by Notes:

Notes Time Zones

The DSTLaw parameter defaults to different values in different versions of Notes. Prior to 4.5.4a and 4.61, all Notes clients and Domino servers followed the North American rules for DSTLaw. In versions 4.5.4a, 4.61, and later, the International clients/servers all follow the European rules for DSTLaw.

Converting a Hexadecimal Value into a Standard Time Value

Given HEX ID 85256468:006724D4, the last 8 characters are 006724D4. This represents the number of ticks (1/100th of a second) that have elapsed since midnight GMT. This value will never be longer than 6 characters since there are only 8,640,000 ticks in a day or 83D600. You can mathematically figure out what this hex value is in hours, minutes, seconds, and ticks by using math, a Spreadsheet like Lotus 123, @functions, or LotusScript. Here is how it's done:

First convert the HEX value to Decimal (@Hex2Dec function in 123, or Windows Calculator):
006724D4 = 6759636

Next divide this number by 100, and multiply the remainder by 100 to get the number of ticks (Mod operator in LScript, @Modulo Notes Function, @Mod 123 function):
6759636/100 = 67596.36
.36 x 100 = "36" ticks

Next take the integer of the tick calculation, divide by 60, and multiply the remainder by 60 to get the number of seconds (Int Function in LScript, @Integer Notes Function, @Int 123 function):
67596/60 = 1126.6
.6 x 60 = "36" seconds

Next take the integer of the seconds calculation, divide by 60, and multiply the remainder by 60 to get the number of minutes (Int Function in LScript, @Integer Notes Function, @Int 123 function):
1126/60 = 18.766667
.766667 x 60 = "46" minutes

Finally take the integer of the minutes calculation the number of hours (Int Function in LScript, @Integer Notes Function, @Int 123 function):
"18" hours

So HEX value 006724D4 = 18 hours 46 minutes 36 seconds and 36 ticks since Midnight GMT.

2004/2/12

## Product Alias/Synonym

Lotus Notes Client

### Document information

More support for: IBM Notes

Software version: 8.0, 8.5, 9.0

Operating system(s): Linux, Windows, iOS

Software edition: All Editions

Reference #: 7003019

Modified date: 09 December 2008