When reviewing the dhis2 logs we notice a difference between the local time and the registration time.
Hi @julioriveros: thanks for taking the time to write to us. Welcome to the DHIS2 community of practice!
You might want to check the server time zone that your system is using. You can check this at {your_instance}/api/system/info and look at the serverTimeZoneId. I believe the logs should be recording the time stamps in your server time zone.
If you need to change your server time zone, you can find information in our system admin guide (System Administration Guide - DHIS2 Documentation) (see section " Setting server time zone and locale").
Hi @tzemp
Actually the time difference has big impact on creating new enrollment or event, when the settings forbid to create an enrollment\even with future date. In my case I have a number of countries which covers wide range of time zones and has upto +6 hours differences. So in this case the countries who has positive time differences from the server time, need to wait until server time will pass next day, and at lest will have 0:00 o’clock on the server side. This caused a lot of delay and it was reported long time ago (DHIS 2 Software - Issues - Jira), but since never heard anything back
How is your DHIS2 instance setup? If you use containers, check what time zones are active on the DHIS2 container, the log4j2 timezone is always in GMT but you can change it by editing log4j2.xml.
@WaluQ as I said earlier the countries are located on wide range of timezones. therefore it doesn’t matter which GMT I will setup on the server side. It must be done globally for all users, independently the time zone. I believe it could be done by receiving users time zone, and if there is time difference the server could accept future date, relatively to the server time.
@Ulanbek I think your issue is different from the original question. For your use case, am thinking of using hosting zones in user time zones for now as a workaround. From a server administration point of view, I’d rather see all timestamps by server time.
Thanks @Ulanbek. I agree with Muyunda in that this is a somewhat different issue than the original post. We’ve decided that the system time should be the default reference time for all users of the system, but we generally display time to users in their local time zone.
For that specific issue you linked, you might want to comment again on the ticket to let us know it’s still relevant. We can account for the difference between the server and the local time zone when determining a date is in the future or not, though there may also be reasons we do not do so in the Capture app.
