From kenneth@hexad.dk on February 07, 2011 09:10:13

The "Z" at the end of the filename means that the time is in UTC format: http://en.wikipedia.org/wiki/Coordinated_Universal_Time Since you are in UTC+1, the time is "off" by one hour.

Previous version of Duplicati included the timezone offset, but to be compatible across multiple servers and to cope with daylight savings time offsets correctly, the format was changed to the one you see now, which has no special characters, unlike "2011-02-07T15:17:39+01:00" which causes problems with windows servers and ftp servers.

Status: WontFix
Owner: kenn...@hexad.dk

From ernst.m...@gmail.com on February 07, 2011 11:24:15

First, thank you for your very quick response!
Why do you use the time in the filename, when it is not correct in most countries of the world. The wrong timestamp in the file name is very confusing, and it is important to see at a glance, when the backup was done. Now most users in the world get a false information from the filename, so the time stamp in the filename must be removed, if it is not possible to use the right time in the filename.
But nearly all other backup apps use the correct time in the filename in each country.
So this is a unique disadvantage of duplicati, which no other backup-app has.
But I can understand, that the format with special characters makes problems. These characters are not necessary, but the time must be correct. So in my opinion the status WontFix must be changed.

From kenneth@hexad.dk on February 08, 2011 01:29:03

I see your point about the time being confusing.
I chose the format because duplicity uses it, so at least there is one other tool with the same disadvantage :).

The problem with not using UTC twofold.

First the current timezone offset needs to be recorded, which could be included by replacing "Z" with something like "+01".

One problem that arises from this is that the same time can be represented in multiple ways, such that "15:35Z", "16:35+01", "17:35+02" are all the same. This makes it much more difficult to figure out what files belong together. Especially if the machine that created the files and the machine reading them are using different timezones.

And IF the user makes backups around the daylight savings time switch, there is a whole new set of problems, because the actual time and timezone offset changes. This means that one file could be named "16:35+01" and the next "16:35+02" but they are the same because their creation spanned a DST switch. If the machines that access this backup are using different DST tables, the parsing results may differ.

It is possible to address all these problems but the complications are non-trivial, and the test setup/reproduction of such errors is really difficult as the timezone or time of year makes the problems manifest themselves very rarely.

For this reason I think the timezone offset is only slightly inconvenient, and the fix is likely to cause too many subtle problems. Besides, it is only the filenames that display awkward, inside the application the local time is always displayed.

From ernst.m...@gmail.com on February 08, 2011 12:08:32

I am a Borland Pascal and Delphi programmer. There it is very easy to add one hour to a time, convert the time in a filename-string and store the file with this filename-string.
In the filename I would prefer the simple format "1635" in Austria for UTC-Time 15:35.
I have never seen and would avoid filenames like "15:35Z", "16:35+01", "17:35+02" in Backup-files from other backup-apps. In Cobian Backup everyone can choose the format of the time-stamp in the filename, see http://screencast.com/t/PIlsjrYR4 , but this is not necessary. If you provide an editable field time-difference from UTC time in hours in the personal option settings (default value zero) this would enable a correct time in the filename, and is easier too realize than to get the time-difference from the country setting from the OS, which would be ideal and is used in this way by Cobian Backup and most other apps.

From kenneth@hexad.dk on February 09, 2011 11:35:15

It is very easy to convert between UTC and local time in .Net as well, that is not the problem. The problem is what happens when you use times that are not aligned to a common standard.

I can see that you don't care about the timezone, but just ignoring/omitting it does not change the fact that it exists. If you write files without any timezone information, the results you get from accessing those files will change depending on the timezone settings of the machine that accesses files. In my view the fact that other backup systems ignore this problem is just because they never considered multiple machines accessing the same backup files.

If you use the local time with no timezone offset you can risk generating backups in the wrong order if you create them during a DST switch, where the same time of day occurs twice (when you rewind the clock). I bet that apps that are not using either UTC time or a timezone offset will have problems with creating two backups during a DST switch.

The solution that you propose where the user can adjust the timezone offset will not work because it has to be adjusted during DST, or the time will be wrong anyway. Besides it adds an extra burden on the user, who has to set this correctly before accessing the files, or the times will be wrong inside the app.

If you read the timezone offset value from the OS, you are back at the problem where machine settings affect the outcome of an operation.

From ernst.m...@gmail.com on February 09, 2011 13:20:47

Can it be, that you see a problem, if using duplicati to do backups with targets on online storage e.g. on Amazon S3 in USA with more than one source computer e.g. in Europe, but I and most people use it only for local backups on my hardisk with normally only one computer, maximally 2 computers in a dropbox environment? If this is the reason for the problem, the handling of the timestamps in the filename should depend on online or local backups.
Until now I used Crashplan, Cobian backup, Macrium Reflect, Windows Image backup and Personal Backup. All of them produce backup-files with names with the correct local time in the filename. Try Cobian Backup und you will see it yourself. During the hour, when time is changed from/to summertime I make no backups, because it is in the night. So I cannot say, if backups in this hour would have the correct timestamp too. If not, I prefer to have a wrong time stamp in 1 hour in the year and not in 8759 hours of the year, as the situation is now with duplicati.

From kenneth@hexad.dk on February 12, 2011 08:43:26

Ok, I'll look into making an option for creating the files with local time format instead. I still do not think this is a great idea, but I sense that it is important to you.

Status: Accepted
Labels: -Type-Defect Type-Enhancement

From ernst.m...@gmail.com on February 12, 2011 14:06:26

Thank You for Your activities for a more correct time-stamp.
I am also active with translating to German. I hope I can complete the translation in 2-4 weeks. I did not think, that it are more than 1000 strings.