Timezone and filesystem

Submitted by hegjon on Wed, 03/28/2007 - 10:19.

When we are dealing with timestamps (created/modified), how should we handle timezones in the filesystem API (and maybe in JNode general)?

Now we are using long to get/set the date, and loose the timezone information.

IS0 9660 supports timezone, how is the timezone support in other filesystems?

‹ The Accessing of a File in Jnode File Systems VBE Infos ›

Universal Time

Submitted by Matt on Sat, 03/31/2007 - 20:06.

I don't know exactly how other file systems do this, but I think it's best to assume that (a) files can be transfered from one timezone to the other (through FTP and such), and (b) computers containing files can be transfered from one timezone to the other. I think it's best to use some form of Universal Time (GMT perhaps?) and when displaying the date convert it to local time using the timezone information provided by the user.

This will make sure the creation date is always correct, and no errors can be made when transferring from one time zone to another.

Because if you store timezone information along with the time, which time are you going to display in a 'ls' or 'dir' command? The time with the timezone info (so now times in one folder can be from two different time zones and sorting will be hell) or just the creation time, translated to the local time? I think the later is best.

Does anyone foresee any other problems?

Machine timestamps should not have timezones

Submitted by Stephen Crawley on Sat, 03/31/2007 - 22:55.

I agree. A timestamp denotes an instant in time, and (ignoring relativity; i.e. differences in physical timeframe) a given instant in time is the same everywhere, independent of the observer's timezone.

In every operating system I know of, native filesystem timestamps are stored without timezone information. This even includes clunky old OS's where the system clock was in local time and you needed to adjust the clock by hand for DST shifts. (Well designed OS'es have always used UTC for the system clock.)

The timezone (explicit or implicit) of a displayed timestamp is something that a human being uses to relate the timestamp to his personal frame of reference, or the frame of reference of some other person. For example, if I log into a computer in the UK, I'll be interested in when a file on that computer was created relative to my current timezone (US Pacific Time) not the timezone in which it was originally created. Indeed, the timezone in which a file was created can be downright misleading; e.g. if the media holding the file is physically transported to a different timezone.

Ideally, timezones should be added to timestamps only when they are displayed to the user, and this should be done according to the user's preferred timeframe for the task he/she is performing.

(Another example, have you ever been confused trying to manually track an email message's transit times from its RFC822 headers? It would be so much easier if they were all UTC times.)

The fact that ISO 9660 includes timezones in timestamps simply tells me that the standard committee wasn't thinking about the issue very deeply. (Having done some standards work in the past, I can tell you that they are NOT the fount of all knowledge! A common problem with standards is that they can lead to bad ideas/decisions being set in concrete. Fixing a standard is often a lot harder than creating it in the first place.)

I'm not aware of any other

Submitted by Peter on Wed, 03/28/2007 - 11:41.

I'm not aware of any other filesystem supporting timezone information. I know the messages like "your clock may be screwed" after switching the timezone in Linux Smiling
I think the easiest way is to read/write it in the user's timezone. I.e. only a long is stored, the interpretation depends on system timezone (not yet present in JNode) or perhaps on the locale.