LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

String to Timestamp attempt at general solution

Most discussions of converting a string to a timestamp in LabVIEW center around specific date-time formats. A general-purpose solution for many common formats might be nice. Consider:

  • Year first, month first
  • Various date delimiters, such as - or . or \ or /
  • 24 vs 12 hour
  • With or without AM/PM
  • One or two digits for the hour
  • With or without seconds
  • With or without fractional seconds
  • Various amounts of white space separating the fields

 

The attached VI attempts to handle these variations, for date or date-time string inputs. I'm sure it can be improved/expanded, and would love some input on this.

 

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 1 of 7
(2,670 Views)

 

What about 2 digit years? That would make parsing impossible!

 

What about time first ("11:12:13 1-1-2018")?

 

Sometimes people use YYYY:mm:dd, some use dd:mm:YYYY, others mm:dd:YYYY. It's just not possible to distinguish between the last two.

 

ISO 8601 (dating 1988) came 20 years too late... It's still ignored.

 

As long as you require years to be 4 digits, why not use \d{4}?

 

Why are months optional ("\d*")? Shouldn't that be "\d{1,2}"? Or even "([1-9]|1[0-2])"?

 

But you can make things more robust by forcing for instance the same separation character for dates and times:  2012\10-09 makes no sense, and should not be allowed. Consider using back references ("(\d)([|\\/.-])(\d)\2").

 

Something like "([1-3][0-9]{3})([\\/:-|.])(([1-9]|1[0-2])\1([1-9]|1[0-9]|2[0-9]|3[0-1])" might make it a bit more robust (untested).

 

Some separation characters are optional, even if there is no digit before it. For instance "2111-11-10  11:11:" is accepted...

 

You might be chasing rainbows. Which is OK as long as you're having fun doing it...

0 Kudos
Message 2 of 7
(2,599 Views)

I often use a time format of "YYMMDD-HHMMSS" : no luck with your "general solution" VI. (And yes, it will be hard to impossible to get the difference of YYMMDD and HHMMSS with current range of years: Today I would get timestamps like "180325-180910"…)

 

IMHO there are way too many different timestamp formats it will be very hard to support all of them. And be aware of language-dependend month names!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 3 of 7
(2,584 Views)

Here's to chasing rainbows: thank you for the input!

 

 


What about 2 digit years? That would make parsing impossible!

 

Yes, I am assuming I'll have have 4-digit eyars, since two-digit years were largely abandoned after the year 2000, and should not be used! You are right you can't parse a 2-digit year in a date string unambiguously. That's off the table for this exercise.

 

What about time first ("11:12:13 1-1-2018")?

 

This could be handled fairly easily, but I've never seen time first in an (apty named) date-time string and that would be pretty non-standard. Is this worth pursuing?

 

Sometimes people use YYYY:mm:dd, some use dd:mm:YYYY, others mm:dd:YYYY. It's just not possible to distinguish between the last two.

 

I have never seed dd:mm:YYYY used, but you are right these woudl eb impossible to distinguish. I'm not going to coverthis corner case.

 

ISO 8601 (dating 1988) came 20 years too late... It's still ignored.

 

As long as you require years to be 4 digits, why not use \d{4}?

 

We can't specify the number of digits if we don't know which position the year is in. Hence, the date legnths are not specified. We have to assume some reasonable input and validate after the parsing.

 

Why are months optional ("\d*")? Shouldn't that be "\d{1,2}"? Or even "([1-9]|1[0-2])"?

 

It was not my intention to make months optional. Let me review this.

 

But you can make things more robust by forcing for instance the same separation character for dates and times:  2012\10-09 makes no sense, and should not be allowed. Consider using back references ("(\d)([|\\/.-])(\d)\2").

 

This is a great point, and I will do this. I had this same worry andc wasn't sure how to work around it. A back reference is the way to go!

 

Something like "([1-3][0-9]{3})([\\/:-|.])(([1-9]|1[0-2])\1([1-9]|1[0-9]|2[0-9]|3[0-1])" might make it a bit more robust (untested).

 

Though I agree here, I want to assume that an actual date string is supplied. It might be better/clearer to validate the results after the regex.

 

Some separation characters are optional, even if there is no digit before it. For instance "2111-11-10  11:11:" is accepted...

 

Good point, I'll look at this!

 

You might be chasing rainbows. Which is OK as long as you're having fun doing it...

 

Yes, very fun!!!

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 4 of 7
(2,544 Views)

Thanks Gerd, my post was not a solution to a problem, but a(n incomplete) proposal. I for one would not use a date-time format like that you've proposed, as it is highly non-standard and ambiguous. I'm looking for a general solution to the most commonly employed date-time formats. It's hard to know what these might be, but looking at standards used by databases and ISO seem to be the best starting point. Of course the possibility of generalizing to all formats is impossible. 

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 5 of 7
(2,540 Views)

@littlesphaeroid wrote:

Here's to chasing rainbows: thank you for the input!


What about 2 digit years? That would make parsing impossible!

 

Yes, I am assuming I'll have have 4-digit eyars, since two-digit years were largely abandoned after the year 2000, and should not be used! You are right you can't parse a 2-digit year in a date string unambiguously. That's off the table for this exercise.

 

What about time first ("11:12:13 1-1-2018")?

 

This could be handled fairly easily, but I've never seen time first in an (apty named) date-time string and that would be pretty non-standard. Is this worth pursuing?

 

Sometimes people use YYYY:mm:dd, some use dd:mm:YYYY, others mm:dd:YYYY. It's just not possible to distinguish between the last two.

 

I have never seed dd:mm:YYYY used, but you are right these woudl eb impossible to distinguish. I'm not going to coverthis corner case.

 

ISO 8601 (dating 1988) came 20 years too late... It's still ignored.

 

As long as you require years to be 4 digits, why not use \d{4}?

 

We can't specify the number of digits if we don't know which position the year is in. Hence, the date legnths are not specified. We have to assume some reasonable input and validate after the parsing.


The timestamp only visualize years between 1600 and 3000 properly. Under the hood (calculations included) it works fine for years beyond those limits. I'd say it would be acceptable to expect years to be 4 digits, but no forcing it is just another way to deal with it.

 

dd:mm:YYYY (or dd:mm:yy) is the standard in the Netherlands. See for instance this random Dutch page on language advice. April the 14th 2011 is 14-04-2011... It's based on speech, we would say the 14th of April, not April the 14th...

 

We're not the only one: Listing of countries with their preferred date formats. In fact, it seems to be 'just' the previous English colonies that use MM\dd\YYYY.

 


@littlesphaeroid wrote: 

Why are months optional ("\d*")? Shouldn't that be "\d{1,2}"? Or even "([1-9]|1[0-2])"?

 

It was not my intention to make months optional. Let me review this.

 

But you can make things more robust by forcing for instance the same separation character for dates and times:  2012\10-09 makes no sense, and should not be allowed. Consider using back references ("(\d)([|\\/.-])(\d)\2").

 

This is a great point, and I will do this. I had this same worry andc wasn't sure how to work around it. A back reference is the way to go!

 

Something like "([1-3][0-9]{3})([\\/:-|.])(([1-9]|1[0-2])\1([1-9]|1[0-9]|2[0-9]|3[0-1])" might make it a bit more robust (untested).

 

Though I agree here, I want to assume that an actual date string is supplied. It might be better/clearer to validate the results after the regex.

 

Some separation characters are optional, even if there is no digit before it. For instance "2111-11-10  11:11:" is accepted...

 

Good point, I'll look at this!


There's always a trade off between robustness and flexibility. It's just that in this case the boundaries of the problem are not very clear.

 

It would be a good idea to set up a primitive test bench, with all the different flavors you want to support, just so you can change the implementation and immediately know which pass and\or fail. It's an investment, but sooner or later you'll find that it's costing you time if you don't have it. 

 

0 Kudos
Message 6 of 7
(2,503 Views)

What date is this: 03/04/05 ?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 7
(2,498 Views)