Date and time rule attributes

SLDTOBS and ULDTOBS

SLDTOBS and ULDTOBS are attributes that tell Lawson Security if the server (SLDTOBS) and user (ULDTOBS) observe Daylight Savings Time (DST).

These attributes are set to true by default. If the server location does not observe DST, you must disable (set to false) the SLDTOBS and ULDTOBS attributes for all affected users. If the server observes DST but a remote user does not, set the ULDTOBS attribute to false for the user only, not the server.

UTZOFFSET

This attribute shows the difference in hours between the server and the user's location. By default, this attribute is set to 0; you must update it for remote users in different time zones.

Use positive and negative numbers relative to 0 to specify this value. To determine if a value is positive or negative, assume that a value "east" of the server is positive, a value "west" of the server is negative and that the server location is "0".

Examples:

If the server is in Chicago and the remote user is in New York, change UTZOFFSET to "1" to show that there is a one hour time difference between Chicago and New York. (In this case, the user is located east of the server so the value is positive.)

If the server is in Chicago and the remote user is in Los Angeles, change UTZOFFSET to "-2" to show that the time difference is two hours. (In this case, the user is located west of the server so the value is negative.)

Week Day Expression

Use this attribute to define a work week for users whose weekly work schedule is nonstandard.

Week Day Expression is pre-populated with the formula (d>0&&d<6), which indicates Monday through Friday, the standard working days for many people. For users who have nonstandard work weeks, you might have to modify the formula, depending on the kinds of rules you write.

The "d" stands for current day of the week and 0–6 are numbers that represent weekdays where 0=Sunday and 6=Saturday. The default expression, d>0&&<6 says: If the current day is greater than Sunday (0) and less than Saturday (6), the rule should execute.

If you plan to create a rule that a particular user could access a particular securable object on his or her working days and the working days are not Monday through Friday, you could change the days. Suppose that a user's working hours are Sunday through Thursday. In this case, the expression should be changed to (d>=0&&d<5).

Most of the time you wouldn't want to create a time/date rule for just one user. Having many specific rules can be hard to maintain and a burden on system resources. It would be more typical to assign a rule of any kind to a role or a thing object (to, for example, lock down a data source during nonworking hours). In the case of date/time based rules which, by definition, are complex, it is especially important to group rules whenever possible.