BitShares Forum

Main => General Discussion => Topic started by: Ivnoidea on September 16, 2015, 03:24:00 am

Title: Some thing about ntp and localtime in early version of bitshares
Post by: Ivnoidea on September 16, 2015, 03:24:00 am
sorry for my poor english.
We have a project based on earlier verison of bitshares before 2015.3。
Now we have some problem about ntp in bitshares and local time。
between ntp in bitshares quests,if localtime of the node(producing block)  is modified,such as ntp in windows ,this may cause fork.
is there any way to avoid fork caused by changing local time

Title: Re: Some thing about ntp and localtime in early version of bitshares
Post by: onceuponatime on September 16, 2015, 04:04:28 am
Welcome.

Tell us a little bit about your project.
Title: Re: Some thing about ntp and localtime in early version of bitshares
Post by: xeroc on September 16, 2015, 11:03:51 am
welcome,

NTP is UTC time as far as I recall. So you could set your local time to UTC too to avoid issues like that .. not sure how windows handles different timezones though
Title: Re: Some thing about ntp and localtime in early version of bitshares
Post by: testz on September 16, 2015, 11:21:25 am
welcome,

NTP is UTC time as far as I recall. So you could set your local time to UTC too to avoid issues like that .. not sure how windows handles different timezones though

Windows handles different timezones well, to make delegates work perfectly at Windows you need to configure NTP time synchronization with external source (same for any other platforms):
https://csg.trinhall.cam.ac.uk/tips/ntp/winxp

Edit: My old post about this: https://bitsharestalk.org/index.php/topic,5767.msg77791.html#msg77791
Title: Re: Some thing about ntp and localtime in early version of bitshares
Post by: monsterer on September 17, 2015, 12:36:26 pm
between ntp in bitshares quests,if localtime of the node(producing block)  is modified,such as ntp in windows ,this may cause fork.
is there any way to avoid fork caused by changing local time

Yes, this is true - I have encountered this issue myself. The only way to resolve it was to get a checkpoint (provided by xeroc in my case) and then re-sync the chain.