Large companies and databases that deal with multiple time zones must deal with Time Zones, otherwise let's assume this scenario,

Let's assume that we have a Mail Server, the database is in London where the universal time is Greenwich Mean Time (GMT), and let's assume that User A

sent an email from Riyadh to Brasilia at exactly Ten o'clock (10) Saudi time (three hours after Greenwich Mean Time)

While the time in Brazil is three hours before Greenwich Mean Time, when the message is sent it will be stored in the database in London at Greenwich Mean Time,

i.e. the time the message was sent will be stored at seven o'clock (7) but when user B views the message in Brasilia The sending time will appear to him at four o'clock (4)

But the field that indicates the sending time must be of the type TIMESTAMP WITH LOCAL TIME ZONE.

It is possible to do this work programmatically, but it requires a lot of work in addition to a great knowledge of time zones and also summer and winter time for some areas,

The database can do anything For you, but notice with me in the previous scenario, what if we ignored the subject of Zone Time? There is no doubt that the process of knowing the time of sending the message in local time will be a very complicated process, as the message will be stored in the local time of Riyadh, and the moment the message is reviewed

In Brasilia, the local sending time of Riyadh will appear (10) while the local time of Brasilia is (4). There is no doubt that this is very influential.

The Database Time Zone can be set at the time of database creation or later via the command ALTER DATABASE SET = TIME_ZONE

If not set, Oracle database picks up the Time Zone from the operating system.

For the client, the Default Time Zone will be set by the operating system or through the environment variable ORA_STDZ.

As for the Session, the Time Zone can be specified via the command ALTER SESSION SET TIME_ZONE=TIME_ZONE

All Time Zones supported by the database can be viewed via V$TIMEZONE_NAMES View.