Namaskaara,
The strike price format in these json files for NSE F&O is stated as thus:
Field_Name: expiry
Type: date
Description: The expiry date of the future.
However example for expiry both in website and in the json file is as follows:
“expiry”: 2111423399000,
That is no format for date anywhere in the world.
I have a strong suspicion that the number value represents UNIX epoch in seconds…
Is my suspicion correct?
Date format used throughout the world is ISO 8601… IN yyyy-mm-dd format…
here too that is all is required.
Can somebody tell me why they complicated a simple date representation to such a complex entity of UNIX EPOCH Seconds ??
Regards
Rathnadhar K V
The value “expiry”: 2111423399000 is in UNIX epoch time (milliseconds) — a standard format for machines. It’s used because it’s precise, fast to parse, timezone-neutral, and easy for systems to work with. While ISO 8601 is human-friendly, epoch time is better for code and performance.
Namaskara,
After coding in Linux for 25 years… I can confidently tell you that conversion form date:yyyy_MMM_dd format to unix milliseconds takes less than 1 millisecond on a 2.5G machine (which is the normal processor speed of Xeon machines, last gen).
I code in C++.
C++23 code is as thus:
UNIX_TIME_STAMP expiry = duration_cast((sys_seconds{sys_days{in_order_mandate_unique_handle_ref->order_expiry_date}} +hours{15} + minutes{29} + seconds{59}).time_since_epoch()).count();
Return value is UINT64 data type.
So for a trade off 1 millisecond/transaction, is it worth to make is human unreadable was my question. Making it human readable would have enhanced the readability of code and also reduce the mistakes… say even if reduce the millisecond by 1 … they dont match… that is the issue.
it would have been much better
expiry = 23/Jun/2025.
We know the last traded order is at 15:29:59 hrs IST… so time zone is IST and no Daylight Saving Time issue here.
that is more readable and less error prone.
Please make API human readable than machine compatible.
Regards
Rathnadhar K V
You can always make it human readable your self. API is for machines. website is for humans.
Namaskara Kishlay,
I know that I have been coding for 25 year in C++ and in Embedded systems. I design MCUs.. so I know down to instruction set of more than 27 micro processor families Ok
API is NOT FOR MACHINES, it’s a human interface between Human and machine… for eg even OS is a human interface between humans and machines … If you have an opinion that API is for machines then you are wrong.
API must be as human readable as possible .. If it’s machine readable then I should code in Machine Language (or even in assembly language) and not in higher level languages.
More human readable, less error prone and fool proof the system will be. API as name states is an interface …not a language…its a human readable interface to a machine and NOT OTHER WAY
Let look at this MACHINE READABLE IMPLEMENTATION: The tolerance of this implementation is just 1Millisecond… Yes, that is the minimum tick of Unix Epoch Sub Second Value. If the number is off by even one least significant digit, there is an exception. Further the resolution for exchange is at 1 second and not millisecond…meaning … HH:MM:SS on expiry is at 15:29:59 IST . But the sub second is fixed to zero as its impossible to slice the second due to network constraints on expiry.
On the other hand, if it had coded in YYYY/MM/DD then the tolerance of implementation is 24 hours… and easily readable. So errors are caught and fixed easily at the developer end. Further easier to document (ledger) …here the hours can be internally fixed by API depending on exchange closure (NSE, BSE or MCX)… that is even more fool proof. Hence I suggested this.
If you could get the above difference then you will agree with my conviction…
Regards
Rathnadhar K V
Hi,
See your implementation requires human readable format. then you can convert it to human readable format in 1 ms. But for rest of us, we will have to convert the human readable date to unix timestamp, and collectively waste 1 ms each, which would be wasteful.
If the number is off by even one least significant digit, there is an exception
You can always check if the expiry value is valid from the contract file before placing the request. Also if one programs the conversion correctly, the conversion should be exact every time in format that the API expects. If you are not doing the conversion manually, I don’t think worrying about off by one digit makes sense.
Thanks.
That is an inefficient and error prone implementation…
Anyhow I will rest my case.