The timezone is set manually by the system administrator usually by providing information on the city/state/country where the computer is located. It can also be set/changed more directly.
The table that contains start/end dates for daylight saving seasons per country/state/timezone gets shipped with the operating system software. So if the government would decide to deviate from the regular daylight savings season start and enddate this might upset a lot of computers.
As it does not change by timezone or daylight savings period, the internal system time is consistent across the world. That makes it an excellent standard for communications between computers, for timestamps in a computer, inter-process communication etc etc.
The Perl functions time(), gmtime() and timegm() all relate to this internal system time. So this is the reason why they do not adapt when day savings period starts.
NB: timegm() is located in the core module Time::Local
There's one problem with the above functions and the system time: unless you happen to be located in the United Kingdom AND the date is outside the daylight savings season the internal system time in UTC will most certainly be different from the date and time locally in your country/state.
This is where Perl function localtime() helps out. It takes the internal system time and applies an offset to it based on timezone and DST information to calculate the locally applicable date and time.
In reply to Re: Time Issues
by varian
in thread Time Issues
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |