$LFILEPROPERTIES MODIFICATIONDATE

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

We have an automatic update system to update the customers, which compares MODIFICATIONDATE of the file on our server with the same property of the file on the customer server.  When the clocks change for BST over GMT, all the modfication dates of the files on the server jump by an hour, meaning that they are all needlessly updated to all of our customers.  Is there a way to get the modificationdate of a file in GMT or UT? It does not seem to matter whether the file is created during GMT or BST, they all jump by an hour on change of dates.    Iain

6 Comments

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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  2. 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.  


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  3. 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


    Author: ulrich-merkel (ulrichmerkel@web.de)
  4. 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


    Author: istiller (i2stiller@gmx.de)
  5. 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. 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  6. 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


    Author: istiller (i2stiller@gmx.de)