First off, What problem are you trying to address here? So far, you've wanted a) help reading tztab, b) help because timestamp changes when the file is transferred and c) help getting the timezones set up and properly reporting.
For Item B:
If the problem is that the timestamp on a "transferred file" is changing, that is because is a "new" file on the system it is being transferred to, so the system is marking it w/ a create time equal to the time of transfer. That's just how it works in a normal environment. My first guess is that the cron job that does the transfer doesn't "run constantly" as noted above, but rather is scheduled, perhaps every hour, and that fact results in the timestamp being one hour different than you are expecting. Timestamps simply are *not* preserved when the file is transferred. All of this has been explained previously.
For Item A:
First, read the man pages on tztab, second, change the tztab file back to it's original form. There should be no need for you to edit this file to get the timezones working properly.
NOTE: a quick search on google reveals that the timezone for Albania yields the following info
http://www.timeanddate.com/worldclock/city.html?n=284 for Tirane.
Now, about that entry:
1) # Middle European Time, Middle European Time Daylight Savings Time
2) MET-1METDST
3) 0 3 25-31 3 1983-2038 0 METDST-2
4) 0 2 24-30 9 1983-1995 0 MET-1
5) 0 2 25-31 10 1996-2038 0 MET-1
Line #1 is a comment and can be disregarded. Line #2 is the "name" of the timezone, and is in the form of tzname|diff|dstname, where tzname is the tz name or abbreviation, diff is the offset from UTC, and dstname is the name referrenced for DST. In this case tzname is MET, diff is -1, and dstname is METDST. So far, that's all good.
Lines 3-5 define the "rules" for tz adjustments in the Middle Europe. The fields are as follows from left to right, minute, hour, day of month (range in this case) and year range, and day of week (0=Sunday). These fields are used to find the first minute that the time zone adjustment, specified in the seventh column, is to be applied. The tz adjustment name is in the form of either tzname or dstname, followed by the UTC offset value.
Line 3 says that the METDST is UTC-2. It starts at 3:00 on a Sunday that is between the 25th and 31st. This applies to any year from 1983 thru 2038. So, this year, on 3/26 - Sunday, the time went from 01:59:59 MET to 03:00:00 METDST the following second.
Line 4 doesn't apply (based on year)
Line 5 says the the time changes back at: any Sunday that falls between 10/25 and 10/31, at 2:00am, and that this applies to 1996-2038. So, this year, on Sunday, 10/29, the reported time moved from 02:59:59am METDST to 02:00:00am MET one second later.
All of the above jives with the information noted on the website, so the tztab appears to be correct.
For Item C:
From the website, the correct timezone *is* MET-1METDST (or MZT-1MZTDST will work as well)
1) Make sure that the times reported via "date -u" is correct for each server. It should report the correct UTC. If not, the system clock is going to need to be reset to the correct time. All of the times and timezone reporting information is based on the fact that the clock is set to UTC, and UTC doesn't vary.
2) As noted above, examine the contents of /etc/TIMEZONE to insure that the default timezone is set to MET-1METDST
3) As noted above, check the contents of $TZ in root's environment.
If all of the above is correct on the servers in question, you should be reporting the correct time with the "date" command, and that should be UTC-1 at present.
If this doesn't help you resolve your problem, please restate what, exactly, you are trying to correct, along with sample output *again* illustrating the issue.
