Messages in this thread | | | Date | Fri, 19 Nov 1999 18:06:51 +0000 (GMT) | From | Riley Williams <> | Subject | Re: updating the RTC automagically |
| |
Hi Peter.
> What the various DOS filesystems need is a mount parameter that > says something like the following...
>> Q> mount -t vfat -o tz=MST /dev/hda2 /win95
> You mean
> # mount -t vfat -o tzoff=-420 /dev/hda2 /win95
> ...Or perhaps you meant that mount(8) does the translation?
I meant what I said, especially "something like" - as in "tell the mount command the relevant timezone by whatever means the author thereof implements."
In other words, it's up to whoever maintains the mount command to decide what semantics (s)he wishes to implement. It could easily be that the required semantics for MST would be "tzoff=420" since there is no standard agreement as to the meaning of + and - in that context and both get used in both senses by different people.
At this stage, I would say that the sensible action would be to suggest suchlike semantics to the maintainer of the FAT-based filesystem drivers (Alexander, is that you?) and see what he or she thinks.
Mr(s) FAT driver Maintainer: In your opinion, would there be any advantage to being able to specify a timezone or timezone offset to be used in interpreting the dates stored on a FAT-based filesystem?
If there is, I would image it could be implemented by adding a signed word field to the private mount data for the affected partitions, and have that store the offset in minutes relating to that partition. It would need to be able to handle values between -750 and +750 to deal with the timezone range that I understand exists - the largest offset that I am aware of is 12.5 hours behind GMT for some of the pacific islands near the International Date Line.
Best wishes from Riley.
PS: The kernel versions page is now back online at the URL below, and includes separate sublists both for each kernel series, and for each year of development.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * http://www.memalpha.cx/Linux/Kernel/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |