Hi Iain 1.  NTFS&Co stores the date as n times 100-nanseconds since 1.1.1601. Related to UTC.      What you see with DOS or UnifAce is the converted date to the local timezone. 2. If you switch the timezone and/or sunlight-saving-offset the filetime will NOT be modified. 3. As UnifAce shows you a converted timestamp you have to subtract the offset for the current timezone     To get the offset, you can use the suggested SQL commands :-) Ingo

Hi Iain, perhaps you can set the server so it stays on GMT all the time?

Hmm, then the time on all transactions shown to the user will be 'wrong'. (I.e. they will save an order at 3PM and it'll tell them it did it at 2PM.) Because all our transactions are done by services on the server, which is where the timestamps come from. I know that they will be right for GMT, but they will be wrong for the user. With those two as alternatives, I'd stick with the times on the files being wrong once/twice a year. If I can have some intelligent way of testing them for GMT then I can have my cake and eat it.  

Hi Iain, On the internet, you will find a couple of routines to check if BST should be applied. Just use it to add/subtract the virtual hour in a little PROC to return the normalized MODIFICATIONDATE

Iain Sharp said Hmm, then the time on all transactions shown to the user will be 'wrong'. (I.e. they will save an order at 3PM and it'll tell them it did it at 2PM.) Because all our transactions are done by services on the server, which is where the timestamps come from. I know that they will be right for GMT, but they will be wrong for the user. With those two as alternatives, I'd stick with the times on the files being wrong once/twice a year. If I can have some intelligent way of testing them for GMT then I can have my cake and eat it.    

Hi Iain What about SQL? select SYSUTCDATETIME(),SYSDATETIMEOFFSET() First gives you the UTC-Time, the other the local time including the offset (at the end) Ingo

I'm not sure how I'd apply that. My issue is that the modification time of the files on the server (as per lfileproperties, and possibly even windows explorer) jumps by an hour for the same (un-modified) file twice a year, once forward, once back... So a file saved at 21/02/2012 10:00:00 reports itself modified at 21/02/2012 11:00:00 for half the year, and then goes back again. We use file modification dates to prompt patch updates amongst other things, and this causes un-necessary updates.  I am looking for a method of 'stabilising' the modification time reported by the file, without removing the GMT/BST switch from the server.  The sysutcdatetime function will tell me whether I am currently in BST, but not which files have changed their modification dates.