Different filesystem types also have different time granularity – eg FAT32 and 
NTFS, one way this manifests is as if a utility such as XCOPY /U  to copy later 
files from one volume type to another, and if the same command is repeated the 
same files may be copied again, because the timestamps are slightly different.


FAT - 2 seconds
exFAT - 10 milliseconds
NTFS - 100 nanoseconds

Changes in DST are processed differently also depending on whether the PC has 
been rebooted since the last DST time change

To give a hint at the complexity - more info from

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx
A file time is a 64-bit value that represents the number of 100-nanosecond 
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated 
Universal Time (UTC). The system records file times when applications create, 
access, and write to files.

The NTFS file system stores time values in UTC format, so they are not affected 
by changes in time zone or daylight saving time. The FAT file system stores 
time values based on the local time of the computer. For example, a file that 
is saved at 3:00pm PST in Washington is seen as 6:00pm EST in New York on an 
NTFS volume, but it is seen as 3:00pm EST in New York on a FAT volume.

Time stamps are updated at various times and for various reasons. The only 
guarantee about a file time stamp is that the file time is correctly reflected 
when the handle that makes the change is closed. 

Not all file systems can record creation and last access times, and not all 
file systems record them in the same manner. For example, the resolution of 
create time on FAT is 10 milliseconds, while write time has a resolution of 2 
seconds and access time has a resolution of 1 day, so it is really the access 
date. The NTFS file system delays updates to the last access time for a file by 
up to 1 hour after the last access.




From: Ross Levis 
Sent: Friday, November 25, 2016 12:57 PM
To: 'NZ Borland Developers Group - Delphi List' 
Subject: Re: [DUG] Timezones for Bills and things

Yep, so some devices are showing daylight savings time and others are not for 
the same physical file, proving the file is stored in UTC and being displayed 
in local time.

 

From: [email protected] 
[mailto:[email protected]] On Behalf Of Rohit Gupta
Sent: Friday, 25 November 2016 10:48 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Timezones for Bills and things

 

Not quite.  Because I am not referring to the actual timestamp that it is 
showing me.  But the fact that between the 5pcs, a laptop and surface and usb 
harddisk.  The timestamps are different twice a year.  If it was storing them 
as utc then they would all be always in sync with each other.  They would all 
change by the same hour and look the same in beyond compare.  But different 
files change their timestamps on different pcs.  If its storing them as utc 
then it is selective about it.  Which is worse than not saving them as utc.  

Rohit

On 25/11/2016 10:06, David Brennan wrote:

  Hi,

   

  Surely that is evidence that Windows is storing timestamps in UTC? If it 
wasn’t then a file stamped as 3pm would always say 3pm no matter what timezone 
you changed your computer to.

   

  Regards,

  David.

   

  From: [email protected] 
[mailto:[email protected]] On Behalf Of Rohit Gupta
  Sent: Friday, 25 November 2016 9:59 a.m.
  To: NZ Borland Developers Group - Delphi List 
mailto:[email protected]
  Subject: Re: [DUG] Timezones for Bills and things

   

  Thanks Ross,

  however I would dispute that windows stores file timestamps in utc.  Because 
twice a year there is mayhem as only some files change their timestamp by an 
hour.  And these files are different on different workstations.

  Maybe it's true for the server version of windows.

  Rohit


  On 24/11/2016 17:39, Ross Levis wrote:

    I suggest store in UTC, like Windows does for file timestamps, and use 
Windows functions like GetTimeZoneInformation and 
SystemTimeToTzSpecificLocalTime to convert to locale time for display/printing 
purposes.  A timezone database shouldn’t be required.

     

    From: [email protected] 
[mailto:[email protected]] On Behalf Of Stefan Mueller
    Sent: Thursday, 24 November 2016 5:21 p.m.
    To: 'NZ Borland Developers Group - Delphi List'
    Subject: Re: [DUG] Timezones for Bills and things

     

    https://github.com/pavkam/tzdb has such a timezone database (2014 data). 
Using that library makes it easy to convert between timezones.

    I think http://www.iana.org/time-zones hosts the latest up to date time 
zone data that this tzdb database is based on in case you want to update it to 
the latest 2016 data. 

     

    Or you could rewrite your application to use Oracle Database … they do have 
a timestamp datatype for your table columns so when you select/insert/update a 
table all you need to do is to set the correct locale and the database will do 
the conversion for you.

    https://docs.oracle.com/database/121/NLSPG/ch4datetime.htm#NLSPG263

     

    Kind regards,

    Stefan Müller,
    R&D Manager

    ORCL Toolbox Ltd. 
    Auckland, New Zealand 


    P Please consider the environment before printing this email

    This message is intended for the adresse named above and may contain 
privileged or confidential information.
    If you are not the intended recipient of this message you must not use, 
copy, distribute or disclose it to anyone.

     

    From: [email protected] 
[mailto:[email protected]] On Behalf Of Rohit Gupta
    Sent: Thursday, 24 November 2016 4:19 p.m.
    To: NZ Borland Developers Group - Delphi List
    Subject: [DUG] Timezones for Bills and things

     

    We finally have to deal with time zones.  We use the server date-time 
everywhere, rather than relying on workstation date-times.  This is not an 
interactive forum type application where the flow of data is merged from 
various timezones.  It is a business management system with appointments and 
bills etc.  The timestamps of these records have to remain as created.  But 
they can not come from the workstation clock.

    Going forward, a database server could be servicing workstations in 
different time zones.

    I am considering

      1.. Set the server time as UTC 
      2.. Keep a table for time zone versus branch (how do I keep this upto 
date at daylight saving boundaries) 
      3.. Use the utc + timezone difference to stamp each bill or appointment 
made for each branch.
    How is everyone else handling it ?

    Regards

    Rohit







_______________________________________________NZ Borland Developers Group - 
Delphi mailing listPost: [email protected]: 
http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to 
[email protected] with Subject: unsubscribe 

  -- 

  Regards

  Rohit Gupta
  B.E. Elec., M.E., Mem IEEE, Mem IET
  Technical Director
  Computer Fanatics Ltd

  Tel 4892280 
  Fax 4892290 
  Web www.cfl.co.nz


------------------------------------------------------------------------------

  This email and any attachments contain information, which is confidential and 
may be subject to legal privilege and copyright. If you are not the intended 
recipient, you must not use, distribute or copy this email or attachments. If 
you have received this in error, please notify us immediately by return email 
and then delete this email and any attachments.






_______________________________________________NZ Borland Developers Group - 
Delphi mailing listPost: [email protected]: 
http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to 
[email protected] with Subject: unsubscribe 

-- 

Regards

Rohit Gupta
B.E. Elec., M.E., Mem IEEE, Mem IET
Technical Director
Computer Fanatics Ltd

Tel 4892280 
Fax 4892290 
Web www.cfl.co.nz


--------------------------------------------------------------------------------

This email and any attachments contain information, which is confidential and 
may be subject to legal privilege and copyright. If you are not the intended 
recipient, you must not use, distribute or copy this email or attachments. If 
you have received this in error, please notify us immediately by return email 
and then delete this email and any attachments.



--------------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with 
Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with 
Subject: unsubscribe

Reply via email to