[PATCH] UTC timestamp option for FAT filesystems - Kernel

This is a discussion on [PATCH] UTC timestamp option for FAT filesystems - Kernel ; (This patch is based on one submitted last year by Paul Collins, but it is updated to work with current source, and it uses a different option name.) Attached is a patch to provide a new mount option ("utc") for ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: [PATCH] UTC timestamp option for FAT filesystems

  1. [PATCH] UTC timestamp option for FAT filesystems

    (This patch is based on one submitted last year by Paul Collins, but it
    is updated to work with current source, and it uses a different option
    name.)

    Attached is a patch to provide a new mount option ("utc") for DOS
    (vfat/msdos) filesystems, allowing timestamps to be in universal
    coordinated time (UTC) rather than local time in applications where
    doing this is advantageous.

    Since DOS filesystems do not contain time zone information, and
    timestamps are typically in local time, a file written in one time
    zone will be wrong when read in a different time zone. When interacting
    with filesystems written or read in Windows, using local time is
    often necessary, but there are other situations in which the
    problems with using local time can be avoided.

    Many digital cameras and other portable devices use vfat, and when
    traveling across time zones it is inconvenient and confusing to
    change the clock setting, but downloading files to a computer in
    a different time zone will result in erroneous timestamps. Also,
    it is often necessary to remember to manually change the clock at
    daylight saving time changes. Forgetting to do this also results
    in incorrect timestamps.

    Setting the clock to UTC is an obvious solution, eliminating
    these issues, but Linux is currently hard-coded to always offset the
    timestamps by sys_tz.tz_minuteswest in order to interpret them as
    local time only. The new mount option removed this limitation.

    -Joe


  2. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson writes:

    > Attached is a patch to provide a new mount option ("utc") for DOS
    > (vfat/msdos) filesystems, allowing timestamps to be in universal
    > coordinated time (UTC) rather than local time in applications where
    > doing this is advantageous.


    The time zone handling seems racy. e.g. consider the case DST
    changes on that day. You convert before the switch over
    and suddenly the time offset is different.

    I'm actually not sure someone in user space is even updating the kernel
    idea of the timezone for DST on a switch (generally it was assumed it's some
    obsolete BSD concept and that all real programs only use the
    user space glibc implementation that knows all the rules). So
    DST might not be supported at all.

    Also even if it worked it seems very limited. If you do that why not
    have an option to set an arbitary time zone offset?

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] UTC timestamp option for FAT filesystems

    Andi Kleen wrote:
    > The time zone handling seems racy. e.g. consider the case DST
    > changes on that day. You convert before the switch over
    > and suddenly the time offset is different.


    Are you saying that the tz code is racy in general (I saw the following thread
    that you responded to as well):

    http://marc.info/?l=linux-kernel&m=115954057716441&w=2

    Or are you saying that the proposed "utc" option makes things racy?

    All the "utc" option does (with this patch) is disable application of the
    kernel's "tz_minuteswest" offset, so using it actually should remove races with
    a DST switch, right?

    > I'm actually not sure someone in user space is even updating the kernel
    > idea of the timezone for DST on a switch (generally it was assumed it's some
    > obsolete BSD concept and that all real programs only use the
    > user space glibc implementation that knows all the rules). So
    > DST might not be supported at all.


    I am not sure about that either (i.e. whether tz_minuteswest is altered on DST
    changes or if it is only changed at boot).

    And I think you are right that the kernel's idea of timezone (i.e.
    "tz_minuteswest") is basically obsolete ("man gettimeofday" talks about this).

    > Also even if it worked it seems very limited. If you do that why not
    > have an option to set an arbitary time zone offset?


    Yes, I thought about also providing an option that lets the user specify the
    offset at mount - this may be useful for other scenarios (like moving Windows
    disks between time zones), but the UTC option, itself, is very useful in that it
    let's one use UTC on FAT devices, which is the least problematic way to do
    things (e.g. for digital cameras, etc.).

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson wrote:
    >> Also even if it worked it seems very limited. If you do that why not
    >> have an option to set an arbitary time zone offset?

    >
    > Yes, I thought about also providing an option that lets the user specify the
    > offset at mount - this may be useful for other scenarios (like moving Windows
    > disks between time zones), but the UTC option, itself, is very useful in that it
    > let's one use UTC on FAT devices, which is the least problematic way to do
    > things (e.g. for digital cameras, etc.).


    After thinking about this some more, I actually do not see much point in
    allowing an arbitrary offset on FAT. Only two modes make sense: local
    time (current default) and UTC (new proposed option). Here's the
    reason: in "local time" mode (the default in Linux and Windows), a FAT
    filesystem records just that to the disk: local time. For example, on
    Windows, it doesn't matter which time zone is in use; a file written at
    12:00 will still show a time of 12:00 even if the time zone is changed
    on the system. If a user with a Windows laptop travels around, changing
    the time zone, files saved at noon in one time zone will appear to have
    the same time when in another. This does not make sense in a "real
    time" sense (it would be possible, for example, to have a file written
    later but with an earlier timestamp if the user crosses a time zone
    boundary to the west (and sets the time zone) just before saving the
    second file). Such a typical traveling Windows user will have files
    saved in many different time zones, so there would be no meaning to
    setting an arbitrary time zone offset when mounting such a volume. The
    files on the volume would just have to considered stamped in "local
    time", wherever the user happened to be.

    Linux's implementation of FAT "local time" mode does this as well. It
    simply adds to a timestamp exactly what the userland level will subtract
    when displaying the time, making that timestamp appear as it is
    numerically on the disk, in local time.

    So FAT filesystem timestamps make sense in one of two modes for a given
    volume: local time or UTC. The former handles volumes used under
    Windows well, and the latter would be extremely useful for other devices
    which use FAT filesystems but need to have a more sensible "real" time
    format (like, as I pointed out, digital cameras).

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson writes:

    > So FAT filesystem timestamps make sense in one of two modes for a given
    > volume: local time or UTC. The former handles volumes used under
    > Windows well, and the latter would be extremely useful for other devices
    > which use FAT filesystems but need to have a more sensible "real" time
    > format (like, as I pointed out, digital cameras).


    Um, so how does the camera show the timestamp of file? UTC seems to be
    hack for changing FAT for Linux. Arbitrary value is more useful and
    correct option, I think.

    It will be specified the timezone of FAT on one disk. So, the timestamp
    is right for specified timezone on Windows always, on Linux should be
    always right. If you want to write, of course, you can specify UTC by it
    to write timestamp as UTC to FAT.

    No?
    --
    OGAWA Hirofumi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] UTC timestamp option for FAT filesystems

    OGAWA Hirofumi wrote:
    >> So FAT filesystem timestamps make sense in one of two modes for a given
    >> volume: local time or UTC. The former handles volumes used under
    >> Windows well, and the latter would be extremely useful for other devices
    >> which use FAT filesystems but need to have a more sensible "real" time
    >> format (like, as I pointed out, digital cameras).

    >
    > Um, so how does the camera show the timestamp of file? UTC seems to be
    > hack for changing FAT for Linux. Arbitrary value is more useful and
    > correct option, I think.


    Since the camera does not have a concept of time zone, the camera's
    clock, itself, would show UTC. You are correct that one could, instead,
    choose an arbitrary time offset when setting the camera's clock, and if
    an option existed in Linux to always use this fixed offset on mount, the
    Linux timestamp could be correct in this case as well.

    However, there are some issues I see with choosing to do this:

    1) It is more confusing than using UTC (the user, in essence, is
    defining a new absolute reference time similar to UTC but not UTC (and
    that matches his local time, at least for 1/2 the year).

    2) If the user moves, either the camera and mount offset could be left
    at the "wrong" setting that would now be less meaningful than UTC, or
    the user could change both.

    3) When the daylight saving time switch happens, the camera's time will
    now be wrong, even though the Linux time will still be OK - they will
    differ by 1 hour unless corrected. If the camera could (and did) adjust
    for DST automatically, then this would give a bad Linux time and
    potentially go unnoticed until the fixed offset were corrected (note
    that my camera does not ever auto-adjust; I'm not sure if any can).

    So in cases 2 and 3, the user would end up needing to change the offset,
    perhaps twice a year. This is one thing I am trying to avoid by just
    using UTC. Using UTC as the "fixed offset" is the only one that makes
    sense in that if one is to choose some arbitrary "universal time", it
    might as well be UTC (and there are no DST issues with UTC).

    > It will be specified the timezone of FAT on one disk. So, the timestamp
    > is right for specified timezone on Windows always, on Linux should be
    > always right...
    >
    > No?


    Not really. Here's an example:

    1) Create a folder on FAT in Windows in winter at local 12:00
    2) Create a folder on FAT in Windows in summer at local 12:00
    3) Notice that in Windows, they both will read "12:00"
    4) Mount the volume under Linux with the default "local time" behavior,
    and you will notice the times are off by one hour (because Linux
    adjusts both by the same offset in the kernel, but userland
    correctly adjusts them differently due to different DST status)

    This is one case in which Linux's method of FAT local time correction
    breaks down, and the real root of the problem is that FAT is not using
    UTC. If, in Linux, the same FAT partition were looked at 6 months
    later, the two times would still differ by one hour, but they would both
    also be shifted by one hour due to the kernel's different DST correction
    (i.e. the "other one" would now read "12:00".

    As I mentioned, local time is not a realistic way to handle time anyway,
    but the paradigm has existed in DOS/Windows FAT throughout its history
    (note that NTFS, on the other hand, behaves more like a real fs).

    So, if one were to, instead of UTC, use an arbitrary "fixed" offset when
    mounting a FAT partition, the same issue would occur (Linux and Windows
    would not agree always).

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson writes:

    > Since the camera does not have a concept of time zone, the camera's
    > clock, itself, would show UTC. You are correct that one could, instead,
    > choose an arbitrary time offset when setting the camera's clock, and if
    > an option existed in Linux to always use this fixed offset on mount, the
    > Linux timestamp could be correct in this case as well.


    It means the timestamp of FAT on the camera is just wrong.

    > However, there are some issues I see with choosing to do this:
    >
    > 1) It is more confusing than using UTC (the user, in essence, is
    > defining a new absolute reference time similar to UTC but not UTC (and
    > that matches his local time, at least for 1/2 the year).
    >
    > 2) If the user moves, either the camera and mount offset could be left
    > at the "wrong" setting that would now be less meaningful than UTC, or
    > the user could change both.
    >
    > 3) When the daylight saving time switch happens, the camera's time will
    > now be wrong, even though the Linux time will still be OK - they will
    > differ by 1 hour unless corrected. If the camera could (and did) adjust
    > for DST automatically, then this would give a bad Linux time and
    > potentially go unnoticed until the fixed offset were corrected (note
    > that my camera does not ever auto-adjust; I'm not sure if any can).
    >
    > So in cases 2 and 3, the user would end up needing to change the offset,
    > perhaps twice a year. This is one thing I am trying to avoid by just
    > using UTC. Using UTC as the "fixed offset" is the only one that makes
    > sense in that if one is to choose some arbitrary "universal time", it
    > might as well be UTC (and there are no DST issues with UTC).


    Of course, UTC is right design for on disk format. But, this is FAT, the
    writing UTC means you modified the design of FAT. It is not a correct
    option, it is just a hack like I said, right?

    However, I can accept that hack for many broken devices on realworld,
    but, the modifying design is not right option. Do you see what I want
    to say?

    >> It will be specified the timezone of FAT on one disk. So, the timestamp
    >> is right for specified timezone on Windows always, on Linux should be
    >> always right...
    >>
    >> No?

    >
    > Not really. Here's an example:
    >
    > 1) Create a folder on FAT in Windows in winter at local 12:00
    > 2) Create a folder on FAT in Windows in summer at local 12:00
    > 3) Notice that in Windows, they both will read "12:00"
    > 4) Mount the volume under Linux with the default "local time" behavior,
    > and you will notice the times are off by one hour (because Linux
    > adjusts both by the same offset in the kernel, but userland
    > correctly adjusts them differently due to different DST status)


    Yes. And sys_tz is wrong and needs to fix.

    > So, if one were to, instead of UTC, use an arbitrary "fixed" offset when
    > mounting a FAT partition, the same issue would occur


    Yes. To store localtime, complex one is needed.
    --
    OGAWA Hirofumi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] UTC timestamp option for FAT filesystems

    OGAWA Hirofumi wrote:
    >> Since the camera does not have a concept of time zone, the camera's
    >> clock, itself, would show UTC. You are correct that one could, instead,
    >> choose an arbitrary time offset when setting the camera's clock, and if
    >> an option existed in Linux to always use this fixed offset on mount, the
    >> Linux timestamp could be correct in this case as well.

    >
    > It means the timestamp of FAT on the camera is just wrong.


    I am not sure what you mean.

    > Of course, UTC is right design for on disk format. But, this is FAT, the
    > writing UTC means you modified the design of FAT. It is not a correct
    > option, it is just a hack like I said, right?


    I do not consider this modifying the design of FAT. FAT does not have
    the concept of time zone, DST, or UTC. It is just a date/time (stamped
    on the volume with no info about what that means). It is customary to
    say these times are in local time, and Windows happens to use it as if
    it's straight local time (Linux tries to emulate this). But using FAT
    to store UTC instead is not changing the design, it is just using it
    differently. I agree this would not be a good idea when sharing a
    volume with Windows, but for cameras, e.g., why not?

    I do see what you are saying, in that the semantics of using FAT imply
    using local time, but I'm not sure this is reason enough to not allow
    someone to adjust how they use the timestamps. After all, if someone in
    Iceland, Morocco, or Algeria writes a file to a FAT filesystem using
    Windows, those timestamps *will* be equivalent to UTC. There is an
    inherent problem with using local time anyway (since someone receiving a
    disk has no idea which time zone was used when writing the file), so I'm
    not sure why it would be wrong to adjust how a particular volume is used.

    > However, I can accept that hack for many broken devices on realworld,
    > but, the modifying design is not right option. Do you see what I want
    > to say?


    If it is a hack (and I do not consider it to be so), I still do not see
    why the utc option is a design change - how else would you get the
    desired behavior?

    > Yes. And sys_tz is wrong and needs to fix.


    I agree it would be good to fix this, but it is probably not trivial,
    and this is a completely independent issue (even if it were fixed,
    things like dealing with DST or moving around with a camera are still
    problematic).

    Also, as I understand it, sys_tz is obsolete, but is still used for
    these legacy things, meaning a new way to flag something as "local time"
    should probably be used ultimately to fix the sys_tz issue.

    >> So, if one were to, instead of UTC, use an arbitrary "fixed" offset when
    >> mounting a FAT partition, the same issue would occur

    >
    > Yes. To store localtime, complex one is needed.


    Right, and I see that as a separate issue. Back to your original point,
    I do not see that letting a user specify a "fixed" arbitrary offset has
    any advantage.

    Summary: I believe it would be nice if the current local time mode were
    fixed to match Windows behavior, but it would also be handy to have the
    utc option for situations where that has advantages.

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] UTC timestamp option for FAT filesystems

    OGAWA Hirofumi wrote:
    > Of course, UTC is right design for on disk format. But, this is FAT, the
    > writing UTC means you modified the design of FAT. It is not a correct
    > option, it is just a hack like I said, right?


    I just looked at the FAT32 specification from Microsoft, and nowhere
    does it say that FAT timestamps are in local time. It does not mention
    local time, time standards, or time zones at all. Here it is:

    http://www.microsoft.com/whdc/system...re/fatgen.mspx

    So there is nothing inherent in FAT's design or specification that
    requires dates and times to be in local time. It appears it is up to
    the OS or device to convey a meaning by how the timestamps are used.
    For this reason, I do not consider it a hack or a design
    change/violation to optionally use UTC for the timestamps on a given FAT
    volume.

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson writes:

    > I do not consider this modifying the design of FAT. FAT does not have
    > the concept of time zone, DST, or UTC. It is just a date/time (stamped
    > on the volume with no info about what that means). It is customary to
    > say these times are in local time, and Windows happens to use it as if
    > it's straight local time (Linux tries to emulate this). But using FAT
    > to store UTC instead is not changing the design, it is just using it
    > differently. I agree this would not be a good idea when sharing a
    > volume with Windows, but for cameras, e.g., why not?


    UTC itself is not wrong. But, I think *"utc" option* is not way to go.

    >> However, I can accept that hack for many broken devices on realworld,
    >> but, the modifying design is not right option. Do you see what I want
    >> to say?

    >
    > If it is a hack (and I do not consider it to be so), I still do not see
    > why the utc option is a design change - how else would you get the
    > desired behavior?


    I think we agreed to fix sys_tz is good thing.

    If so, I'd like to see "tz=xxx" or something for the future, instead of
    "utc", don't you think so? I really hate to add the random options.
    --
    OGAWA Hirofumi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] UTC timestamp option for FAT filesystems

    OGAWA Hirofumi wrote:
    > If so, I'd like to see "tz=xxx" or something for the future, instead of
    > "utc", don't you think so? I really hate to add the random options.


    One question: do you see the "tz=" option having "xxx" being a numerical
    offset or a time zone. If the latter, then the DST situation could be
    solved (and tz=UTC could be used to get the behavior I like, but I still
    wonder if a timezone feature on FAT is useful. Also, would it not
    require the kernel to look up timezone info and keep track of DST
    changes? I thought the trend was to push that kind of thing into
    userland...

    Thanks, Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] UTC timestamp option for FAT filesystems

    OGAWA Hirofumi wrote:
    > I think we agreed to fix sys_tz is good thing.


    Yep, but doesn't have to be fixed before adding a new option, since they
    are separate issues and uses, I think.

    > If so, I'd like to see "tz=xxx" or something for the future, instead of
    > "utc", don't you think so? I really hate to add the random options.


    Can you help be to understand what "tz=xxx" (if not =0) would be good
    for? It seems to me that either you want the "local time" functionality
    (which deals, to a degree, with DST, in which case you use the existing
    behavior) or you use tz=0 (which is the same as utc).

    If someone were to, say, set "tz=-7", it would not work correctly with a
    camera or with a Windows-written volume.

    For a camera, since DST is not taken into account. If you really want
    to set your camera to local time and are willing to accept the inherent
    issues, why not just use local time FAT behavior as it is now in Linux.

    If you are talking about using a Windows FAT partition in a different
    time zone, setting tz=xxx would not help either, since all files are
    just written in local time whichever time zone the person was in (the
    traveling laptop example). Again, the only solution in that case is to
    use the default local time behavior.

    So, which cases benefit from tz=xxx that would not benefit from utc
    (which is eseentially tz=0)?

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson writes:

    > I just looked at the FAT32 specification from Microsoft, and nowhere
    > does it say that FAT timestamps are in local time. It does not mention
    > local time, time standards, or time zones at all. Here it is:
    >
    > http://www.microsoft.com/whdc/system...re/fatgen.mspx
    >
    > So there is nothing inherent in FAT's design or specification that
    > requires dates and times to be in local time. It appears it is up to
    > the OS or device to convey a meaning by how the timestamps are used.
    > For this reason, I do not consider it a hack or a design
    > change/violation to optionally use UTC for the timestamps on a given FAT
    > volume.


    This is not interesting argument. That mentions MSDOS/Windows
    everywhere, you just ignored it.
    --
    OGAWA Hirofumi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH] UTC timestamp option for FAT filesystems

    Joe Peterson writes:

    > OGAWA Hirofumi wrote:
    >> If so, I'd like to see "tz=xxx" or something for the future, instead of
    >> "utc", don't you think so? I really hate to add the random options.

    >
    > One question: do you see the "tz=" option having "xxx" being a numerical
    > offset or a time zone.


    Ah, sorry. I was imagining, e.g. POSIX TZ string like
    "EST5EDT,M3.2.0/2,M11.1.0 " or something, it is not a simple numerical.

    > If the latter, then the DST situation could be
    > solved (and tz=UTC could be used to get the behavior I like, but I still
    > wonder if a timezone feature on FAT is useful. Also, would it not
    > require the kernel to look up timezone info and keep track of DST
    > changes? I thought the trend was to push that kind of thing into
    > userland...


    Yes. If it can do in userland (on embeded system too), it's very
    good. (also, nls stuff is same situation.) But, I'm not sure yet,
    need to think about it.
    --
    OGAWA Hirofumi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. [PATCH] UTC timestamp option for FAT filesystems

    Hi Andrew,

    Attached is a patch to provide a new mount option ("tz=UTC") for DOS
    (vfat/msdos) filesystems, allowing timestamps to be in coordinated
    universal time (UTC) rather than local time in applications where
    doing this is advantageous.

    In particular, portable devices that use fat/vfat (such as digital
    cameras) can benefit from using UTC in their internal clocks, thus
    avoiding daylight saving time errors and general time ambiguity issues.
    The user of the device does not have to worry about changing the time
    when moving from place or when daylight saving changes.

    The new mount option, when set, disables the counter-adjustment that
    Linux currently makes to FAT timestamp info in anticipation of the
    normal userspace time zone correction. When used in this new mode, all
    daylight saving time and time zone handling is done in userspace as is
    normal for many other filesystems (like ext3). The default mode, which
    remains unchanged, is still appropriate when mounting volumes written in
    Windows (because of its use of local time).

    (I originally based this patch on one submitted last year by Paul
    Collins, but I updated it to work with current source and changed
    variable/option naming. Ogawa Hirofumi (who maintains these
    filesystems) and I discussed this patch at length on lkml, and he
    suggested using the option name in the attached version of the patch.
    Barry Bouwsma pointed out a good addition to the patch as well.)

    -Thanks, Joe


  16. Re: [PATCH] UTC timestamp option for FAT filesystems

    >>>>> "Joe" == Joe Peterson writes:

    Joe> For a camera, since DST is not taken into account. If you really
    Joe> want to set your camera to local time and are willing to accept the
    Joe> inherent issues, why not just use local time FAT behavior as it is
    Joe> now in Linux.

    Taking the rôle of Devil’s Advocate, why presume that the camera and the
    box will have the same idea of local time? One might set the camera to
    local time on a vacation, take some pics, return home and only them mount
    the card on one's box.

    Of course, that only works well if one uses different cards for each
    timezone one visits. And it may well be unusual for typical digital
    camera owners to bother with setting the time. But it can't be unknown.

    It does seem likely that anyone who sets the camera's time at all will
    probably prefer localtime. And if they know that one card has photos
    taken during a winter visit to Orlando, and another from a summer trip
    to Alaska, they may want to copy over accurate timestamps.

    -JimC
    --
    James Cloos OpenPGP: 1024D/ED7DAEA6
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH] UTC timestamp option for FAT filesystems

    James Cloos wrote:
    > Joe> For a camera, since DST is not taken into account. If you really
    > Joe> want to set your camera to local time and are willing to accept the
    > Joe> inherent issues, why not just use local time FAT behavior as it is
    > Joe> now in Linux.
    >
    > Taking the rôle of Devil’s Advocate, why presume that the camera and the
    > box will have the same idea of local time? One might set the camera to
    > local time on a vacation, take some pics, return home and only them mount
    > the card on one's box.


    Hi James, I think you have hit squarely on the issue. One could do
    this, and the result would be potentially confusing and incorrect.

    Say someone lives in Denver, and it is summer. The UTC offset here is
    -6 hours. That person travels to the east coast, sets his camera to
    local time there (UTC - 4), and takes a picture at 9:00am. He then
    returns to Denver and transfers the pic to his PC. Using the current
    Linux FAT mount behavior, the picture would be given a timestamp in
    Linux of 15:00 UTC (9:00am local time in Denver, since the code
    preserves the local time stamp, which is 9:00). Now, the picture was
    actually taken at 13:00 UTC (7:00am local time in Denver), and since UTC
    is what matters in Linux, the actual time is two hours off.

    In order to make sense of the timestamp on the picture, he would have to
    remember where the picture was taken and do a time zone correction,
    remembering that the picture was downloaded in Denver preserving local
    time. It's starting to get a bit mind-bending already, but see the
    example of moving to England below for how it can get worse.

    > It does seem likely that anyone who sets the camera's time at all will
    > probably prefer localtime. And if they know that one card has photos
    > taken during a winter visit to Orlando, and another from a summer trip
    > to Alaska, they may want to copy over accurate timestamps.


    Some people will perfer the timestamps be in localtime, but this is
    really problematic, since times in Linux's filesystems (ext3, etc.), and
    even Windows' NTFS, are stored in UTC internally (which is a good thing).

    Now things potentially get interesting...

    Say that same person who took the picture on the east coast at 9:00am
    (but timestamped 9:00am Denver time now) moves to England with his PC.
    He then sets his computer's time zone to his new local time zone, and it
    now says the picture was taken at 4:00pm! He can no longer think of the
    timestamp as local time, but then again it is not even correct in local
    time where the picture was taken, since that would have been 11:00 east
    coast time.

    Now, if the guy had kept his camera on Denver time during his travels
    and no DST change happened between taking the pictures and downloading
    them, the correct timestamps would have been preserved (if DST status
    was different, however, the timestamp would be off by one hour). But if
    one is going to pick a "universal time" that is not necessarily local
    time for the camera while traveling, why not use UTC and avoid all of
    the issues?

    So I guess my point is that the option I propose will allow people to
    set their cameras to UTC and thereby always get unambiguously correct
    timestamps. Plus there is no need to ever change the camera's clock
    when traveling or when DST changes happen. Not all people will choose
    to operate this way, so it would be nice to have the choice.

    -Joe
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH] UTC timestamp option for FAT filesystems

    In article <4867178D.50106@skyrush.com> you wrote:
    > So I guess my point is that the option I propose will allow people to
    > set their cameras to UTC and thereby always get unambiguously correct
    > timestamps. Plus there is no need to ever change the camera's clock
    > when traveling or when DST changes happen. Not all people will choose
    > to operate this way, so it would be nice to have the choice.


    And just as a reminder, tools tend to use EXIF informations anyway.

    Gruss
    Bernd
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH] UTC timestamp option for FAT filesystems

    On Thu, 26 Jun 2008 23:12:05 -0600
    Joe Peterson wrote:

    > New mount option ("tz=UTC") for FAT (vfat/msdos) filesystems allowing
    > timestamps to be in coordinated universal time (UTC) rather than
    > local time in applications where doing this is advantageous (like
    > digital cameras, etc.)


    Can we update Documentation/filesystems/vfat.txt please?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH] UTC timestamp option for FAT filesystems

    On Thu, 26 Jun 2008 23:12:05 -0600
    Joe Peterson wrote:

    > (I originally based this patch on one submitted last year by Paul
    > Collins, but I updated it to work with current source and changed
    > variable/option naming. Ogawa Hirofumi (who maintains these
    > filesystems) and I discussed this patch at length on lkml, and he
    > suggested using the option name in the attached version of the patch.
    > Barry Bouwsma pointed out a good addition to the patch as well.)


    It'd be nice to gather Paul's signed-off-by:. And to add a Cc to
    Barry. That way they get a mention in the kernel logs (pure chick
    magnetry!) and they are presumably people who can help review the
    change for us.

    But I don't know their email addresses.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast