Decimal to Hex conversion

[JÞB]

Tim, could you snip the code for CA and myself?

[alexderjuengere]

---

@deep_217 wrote:

Its a date and time string with hour and minute... not too big but larger then 32bit because year changed to 2022 so instead of 21 we have to use 22 YYMMDDHHMM 

---

https://zone.ni.com/reference/de-XX/help/371361L-0113/lvhowto/numeric_data_types_table/

[JÞB]

Fine, Go ahead and encourage me to actually activate my CE license

[altenbach]

---

@altenbach wrote:
If you want to "compress" this string into a single integer suitable for hex formatting, you can take advantage of the fact that MM are limited to 0..59, HH to 0 .23, DD is limited to 1..31, MM is limited to 1..12. Of course you also need something to convert the hex string back to the date string. 

---

Here's a quick draft. Note that the hex value easily fits into a 32 bit integer. 😄

It is left to the student to figure out what's in the two simple subVIs I quickly made just now. 😄

try it!

(Note that the compressions still contains some hot air for the sake of code simplicity 😉

Don't trust the compressed value shown in the picture, there are probably bugs.... ;)) )

[JÞB]

DD is 1-32 but still fits nicely in 5 bits

[altenbach]

---

@JÞB wrote:

DD is 1-32 but still fits nicely in 5 bits

---

However it is inefficient to tread each field independently. 😄

[LLindenbauer]

---

@deep_217 wrote:

Its a date and time string with hour and minute... not too big but larger then 32bit because year changed to 2022 so instead of 21 we have to use 22 YYMMDDHHMM 

---

Saving time this way is a dangerous idea. Instead of trying to make it work by changing the data type, you should try to solve the problem at the root and change the way the date is saved. This will not only solve this conversion problem, but the person inheriting your code will thank you for it. There are already solutions for saving time. While none of them are perfect, they are almost certainly better than reinventing the wheel oneself.

Just 4 months ago, the mistake of trying to save a string as digits in a numeric type caused thousands of big e-mail-systems to fail: https://docs.microsoft.com/en-us/answers/questions/680488/microsoft-exchange-fip-fs-scan-engine-fail...

[JÞB]

---

@altenbach wrote:

---

@JÞB wrote:

DD is 1-32 but still fits nicely in 5 bits

---

However it is inefficient to tread each field independently. 😄

---

---

Ah a clue to what's inside.  but, I still can't duplicate unless I know if you used 27 or 28 bits.

28 is easy with %j but Minute of Day fits in 9 so 27 is possible too without getting intense. 

Really we need less than 54,900,000 values and that is assuming every year has 366 days (nearly a forth of them do and exactly 1/4th this century ) and every day has 25 hours ( the first Sunday in November might unless the permanent DST bill unanimously approved by the US Senate in March is enacted) so we could get to 26 with plenty of sparse values to play a lot more.

[altenbach]

In any case, things are not future-proof because we'll run into a Y2.1k problem in less than 80 years. 😄

[altenbach]

Easiest would be to just get minutes since Jan 1, 2000 and format in hex. 😄