Database dates and times are stored with unspecified time zone information. This date and time model works perfectly for nearly all of our customers because computer networks are typically contained within a single time zone, so no time zone information is necessary. If all of the computers on your network (including your server) are within a single time zone, the information on this page doesn't apply to you unless you plan to expand your network to multiple time zones in the future.
If your network spans multiple time zones and you are using the Middle Tier, some dates in Open Dental may behave slightly irregularly. The issue only affects areas of the program where a new record is created and today's date is automatically used as the default date.
Example: A saved treatment plan would show yesterday's date if the client machines were in New York and the Middle Tier server was in Oregon. The discrepancy was due to time zone differences. When a new date is created without time information, the default time used is midnight of the generated date. Since the time in Oregon is three hours behind New York, when the date and time combination was sent to the Middle Tier, three hours were automatically subtracted, making the treatment plan date yesterday's date at 9 pm (but then only the date portion was saved to the database). This bug was fixed in version 12.4.
Similar issues may exist in other areas of the program when today's date is automatically used as the default date. If you run into this issue and you are using the latest version of Open Dental, contact support for help.
If using Replication in different time zones, if locations are in different timezones, data will be synced but may not show at all locations.
If you are using a Remote Access app to access an Open Dental database, you may notice that your workstation is using the time zone of the database you are remotely accessing, rather than your local time. This will affect features in Open Dental such as the horizontal time line in the Appointments Module.
If this happens, the solution is to create a group policy to direct the remote server to use the local time zone on the user's workstation for software applications like Open Dental. Note that most times recorded in Open Dental are not affected by group policy, because they use the time zone of your MySQL server and not the workstation time.