On Wed, Feb 13, 2013 at 4:06 PM, Andrey Borzenkov wrote:

В Wed, 13 Feb 2013 15:00:59 -0500 Greg Freemyer пишет:

...

On Mon, Feb 11, 2013 at 10:47 PM, Juan R. de Silva wrote:

...

...

My preferred workaround for the VFAT problem is avoiding use of VFAT.

Unfortunately it may not always depend of a user. E.g. I recently get hit by this bug trying to copy files from my Olympus Voice Recorder to my system.

I still would like to know if there is a bugzilla against this. If there is, I might take a shot at fixing it.

How are you going to fix it? VFAT keeps timestamp in local time. There is no way to know, *which* local time it is. So whatever you do will be wrong for some cases. At the best, you can extend UTC mount option to use timezone offset in case you know from where your USB stick comes from :)

Andrey, Since there was not a opensuse bugzilla entry, I didn't take the time to even check what the issue is. I just kept seeing a reference to a "bug". I took that to mean the linux implementation of something was broken. If the only "bug" is the decision 30 years ago to have FAT based on localtime, then obviously there is nothing that can be done now. fyi: I use FAT analysis software for my day job the allows me to put in the display timezone, and 2 sets of dst settings, and a arbitrary date to control which set of dst settings to use. Thus I can tell it that the filesystem is FAT and that the times were recorded as EST localtime and what the current laws are for DST transition and what they were 10 years ago, and when the law changed. I guess, I was assuming linux offered similar timestamp translation and that there was a bug in translation. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-02-14 06:58 (GMT+0400) Andrey Borzenkov composed:

And actually current fat driver (looking at kernel GIT source) already implements it :)

{Opt_tz_utc, "tz=UTC"}, {Opt_time_offset, "time_offset=%d"},

It does translate from local to UTC. But the problem is summer time changes. Kernel has one number - this is current time zone offset. It does not maintain full table of all summer time changes in the past. This means that e.g. in summer all files created in winter will appear wrong by one hour. Or any file created in the past, when summer time rules were different, will appear with wrong date.

Is the "identical" problem using FTP in MC between machines on a LAN[1] similarly unsolvable? http://lists.opensuse.org/opensuse/2013-02/msg00190.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Feb 14, 2013 at 7:41 AM, Felix Miata wrote:

Is the "identical" problem using FTP in MC between machines on a LAN[1] similarly unsolvable?

http://lists.opensuse.org/opensuse/2013-02/msg00190.html

Before problem can be solved it has to be identified. Wrong time stamp may be e.g. due to settop box not correctly implementing DST changes. Or it may be simply using FAT under the hood :) Or it may be due to FTP server (or MC - I have not touched it for decade at least) not implementing MLSx extension to retrieve time stamp in UTC. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Feb 14, 2013 at 10:08 AM, Felix Miata wrote:

On 2013-02-14 09:48 (GMT+0400) Andrey Borzenkov composed:

...

Felix Miata wrote:

...

...

Is the "identical" problem using FTP in MC between machines on a LAN[1] similarly unsolvable?

...

...

http://lists.opensuse.org/opensuse/2013-02/msg00190.html

...

Before problem can be solved it has to be identified. Wrong time stamp may be e.g. due to settop box not correctly implementing DST changes. Or it may be simply using FAT under the hood :) Or it may be due to FTP server (or MC - I have not touched it for decade at least) not implementing MLSx extension to retrieve time stamp in UTC.

It's an AZBox, no FAT, except USB devices I don't use with it except for firmware updates:

$ uname -a Linux AZBox 2.6.15-sigma #138 PREEMPT Thu Jan 22 21:35:07 KST 2009 mips unknown

I can't find any *elease* file that provides any more info.

What else would it take to get this problem figured out?

I would start with enabling as much debugging output as possible in MC and look at actual FTP chit-chat between client and server. If this is not tpossible, there is always wireshark. This at least will show you whether wrong timestamps come from server or it is client issue. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Feb 14, 2013 at 3:06 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Thursday, 2013-02-14 at 06:58 +0400, Andrey Borzenkov wrote:

...

It does translate from local to UTC. But the problem is summer time changes. Kernel has one number - this is current time zone offset. It does not maintain full table of all summer time changes in the past.

The date command does.

Do you suggest that kernel fat driver should run date command to compute file timestamp? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

2013. február 13. 22:06 napon Andrey Borzenkov írta:

В Wed, 13 Feb 2013 15:00:59 -0500 Greg Freemyer пишет:

...

On Mon, Feb 11, 2013 at 10:47 PM, Juan R. de Silva wrote:

...

...

My preferred workaround for the VFAT problem is avoiding use of VFAT.

Unfortunately it may not always depend of a user. E.g. I recently get hit by this bug trying to copy files from my Olympus Voice Recorder to my system.

I still would like to know if there is a bugzilla against this. If there is, I might take a shot at fixing it.

How are you going to fix it? VFAT keeps timestamp in local time. There is no way to know, *which* local time it is. So whatever you do will be wrong for some cases. At the best, you can extend UTC mount option to use timezone offset in case you know from where your USB stick comes from :)

I don't understand this. If vfat keeps local time, then that local time should be used as local time. The user knows that it is local time. For example if vfat localtime indicates 2012-07-15 16:31:00 it should be translated and implemented as 2012-07-15 16:31:00 in linux, independently from time zone and daylight saving time. And I, the user know if I look at the file's timestamp, that the given picture was taken in Japan last summer, and the timestamp indicates Japanase summer local time. And that is what I need. The computer does not have to know which local time it is and it doe not not have to change it. The time zone offset you mention does not work. It is used by default, and if you turn it off (tz=UTC option) the timeshift becomes 2 hours. man mount: tz=UTC This option disables the conversion of timestamps between local time (as used by Windows on FAT) and UTC (which Linux uses internally). This is particuluarly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

2013. február 14. 17:03 napon Andrey Borzenkov írta:

В Thu, 14 Feb 2013 16:48:27 +0100 Istvan Gabor пишет:

...

2013. február 13. 22:06 napon Andrey Borzenkov írta:

...

В Wed, 13 Feb 2013 15:00:59 -0500 Greg Freemyer пишет:

...

On Mon, Feb 11, 2013 at 10:47 PM, Juan R. de Silva wrote:

...

...

My preferred workaround for the VFAT problem is avoiding use of VFAT.

Unfortunately it may not always depend of a user. E.g. I recently get hit by this bug trying to copy files from my Olympus Voice Recorder to my system.

I still would like to know if there is a bugzilla against this. If there is, I might take a shot at fixing it.

How are you going to fix it? VFAT keeps timestamp in local time. There is no way to know, *which* local time it is. So whatever you do will be wrong for some cases. At the best, you can extend UTC mount option to use timezone offset in case you know from where your USB stick comes from :)

I don't understand this. If vfat keeps local time, then that local time should be used as local time. The user knows that it is local time.

Really? You go to Japan and give USB stick to your friend who copies file there. File has Japanese local time (stamp). Then you go to USA and get second file with American local time. Then go to Europe and get third. Which of three "local times" is correct?

All are correct. It is more relevant than converting time stamps (especially incorrectly) according to computer's time zone. Staying with your example let's assume I take pictures of sundown in different countries, to make it simple, in every country at 6 pm. If the timestamps are adjusted, it results in sundown at midnight, sundown in the morning etc. according to the adjusted timestamps, which is ridiculous. Or I take photos of sunsets in different countries. When I look at the photos at home I would like to know at what times sundowns exactly happened . If the timestamps are adjusted correctly, I have to make elaborate calculations the find out the exact time including time shifts between countries and daylight saving time. If the timestamps are adjusted incorrectly (what seems to be the case currently) I can't even calculate it. Is that what you want? Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

with American local time

Which American local time? There are 5 of them that I'm aware of. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Istvan Gabor wrote:

I don't understand this. If vfat keeps local time, then that local time should be used as local time. The user knows that it is local time. For example if vfat localtime indicates 2012-07-15 16:31:00 it should be translated and implemented as 2012-07-15 16:31:00 in linux, independently from time zone and daylight saving time. And I, the user know if I look at the file's timestamp, that the given picture was taken in Japan last summer, and the timestamp indicates Japanase summer local time. And that is what I need. The computer does not have to know which local time it is and it doe not not have to change it.

Several years ago, I used to work at IBM Canada. I could log into domains across the country. One side effect was my computer clock changed as I connected to domains in different time zones. These were OS/2 servers, but the same problem occurs with Windows. Time & date should always be in UTC and then adjusted for local time, as is the case with Linux & Unix. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org