Default Timevalues Setting in WinSyslog Explained
Question: What is the Default Timevalues setting and how does it affect time handling in WinSyslog, EventReporter, and MonitorWare Agent?
Overview
The General Options in WinSyslog, EventReporter, and MonitorWare Agent contain a setting for “Default Timevalues”. This setting controls how timestamps are handled throughout the system.
Default Timevalues Options
You can set Default Timevalues to:
- UTC (Universal Coordinated Time): The default setting. All internal time calculations use UTC.
- Localtime: Uses the local time zone for certain output operations.
Why UTC is Used Internally
Important: Even when you select “Localtime”, WinSyslog still calculates internally with UTC time. This is necessary to:
- Maintain time accuracy when messages are sent via Syslog or SETP protocols
- Prevent unexpected time differences across time zones
- Ensure consistent timestamp handling in database operations
- Support reliable message forwarding between systems
Where Localtime Setting Has Effect
When Default Timevalues is set to “Localtime”, it affects the following operations:
| Action | Effect |
|---|---|
| Send Email Action | Date in the email header uses localtime |
| Start Program Action | Time parameters in command line use localtime |
| Write File Action | Time properties in file names use localtime |
| Filter Engine | Filtering by weekday or time fields uses localtime |
Getting Localtime Output
For actions where you need localtime output in custom formats, you can use property options:
Property Option: localtime
Converts the output of any timestamp into localtime:
%timegenerated:::localtime%This will display the time in the local time zone.
Property Option: uxLocalTimeStamp
Same output as uxTimeStamp, but uses localtime instead of UTC:
%timereported:::uxLocalTimeStamp%This generates a UNIX-style timestamp based on local time.
Examples
Using UTC timestamps (default):
%timegenerated%
%timereported:::uxTimeStamp%Using localtime timestamps:
%timegenerated:::localtime%
%timereported:::uxLocalTimeStamp%Best Practices
- Keep UTC as default: For most scenarios, UTC is recommended for consistency
- Use localtime option: Apply the localtime property option only where needed
- Database storage: Store timestamps in UTC for accurate querying across time zones
- Display purposes: Convert to localtime when displaying to users
- Log rotation: Use localtime for file naming if you want daily rotations based on local business hours
Additional Notes
- The Default Timevalues setting affects defaults only – individual actions can override this
- UTC-based calculations ensure messages maintain accurate timestamps when forwarded
- Consider your environments time zone distribution when choosing the default
- Most enterprise deployments prefer UTC for global consistency