in reply to Time Issues

Your computer system keeps track of an internal date/time (typically rendered as an integer number or a UTC date) and an offset based on timezone and daylight savings (DST) table information.

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.

Replies are listed 'Best First'.
Re^2: Time Issues
by Anonymous Monk on Mar 13, 2007 at 20:30 UTC
    Thanks everyone for the suggestions... My only problem with using the localtime() is I have users from different timezones using the app... if I use the localtime() it will pull which ever time the user is on and put in.. which is becoming messier while tracking and in the audit trail so I used gmtime to make time fixed to Eastern US time zone...Is there a easy way to figure out the time zone a user is in so that i can use the offset from UTC?
      My only problem with using the localtime() is I have users from different timezones using the app... if I use the localtime() it will pull which ever time the user is on and put in.. which is becoming messier while tracking and in the audit trail so I used gmtime to make time fixed to Eastern US time zone...Is there a easy way to figure out the time zone a user is in so that i can use the offset from UTC?

      We need to know more about how your users interact with the application. If they are logged on to the server then localtime will return the server's local time unless they set the TZ environment variable. If we are talking about a web-based application then the application will only know about the server's local time unless you ask the users to tell what their local timezone is.

      My recommendation would be to store all times in UTC (as that's the only timezone guaranteed not to change). Store your users' local timezones in their user configuration details and use that data to translate UTC to their local time when displaying data to them (or accepting data from them).

      ask your users