Colons in date formats for STRT/STOP confuse parser

[dmendres]

Running lasio (0.24.1) on Python 3.6.8.

The LAS2 specification states that the text FOLLOWING the last colon is a delimiter.
Quoting LAS_20_Update_Jan2014.pdf:

• The delimiters in a non-comment line are the first dot in the line, the first space after that dot and the last colon in the line. (clarification)
• Most LAS 2.0 files have a depth based index however a time based index is permitted (clarification).

However, LASIO parses the description starting with the first colon so the following DateTime STRT and STOP are parsed as follows:
~Well
STRT.DateTime 2012-09-16T07:44:12-05:00 : START DEPTH
STOP.DateTime 2012-09-18T08:36:10-05:00 : STOP DEPTH
…

With the following result:
(Pdb) p las.well.STRT
HeaderItem(mnemonic=STRT, unit=DateTime, value=2012-09-16T07, descr=44:12-05...)

[kinverarity1]

Thanks for raising this issue, we will look into it 👍🏻

[dcslagel]

Hi @dmendres , @kinverarity1 ,

It looks like this issue was fixed after lasio (0.24.1). You should be able to upgrade to the current version 0.28 and get the correct parsing of the time value into the value field.

To verify, I added the above example as a test to the pull-request: #420. In the pull-request checks, it has passed on all versions of Python. Could you update your Laiso version and re-try the las file?

DC

[dmendres]

Thanks! I've confirmed that the STRT, STOP fields containing DateTime values with embedded colons are properly parsed in version 0.28.1. However, if the header is written back to a string, the unit is incorrect. Using the attached test file:
LAS2DateTime.LAS.gz
My utility is able to process the DateTime, but look at the STRT. and STOP. unit in the header output:

python LAS2Text.py test\LAS2DateTime.LAS | jq .
[
  [
    {
      "font-size": 18,
      "txt": "ANY ET AL 12 34 12 34 LAS2 File"
    },
    {
      "font-size": 10,
      "txt": "On 13-DEC-86, ANY LOGGING COMPANY INC. logged the ANY ET AL 12-34-12-34 well for ANY OIL COMPANY INC. operating for **0.9 hours**.  The well is located  in the province of ALBERTA.  The following log curves were measured: DEPT, RHOB, NPHI, MSFL, SFLA, ILM, ILD, SP."
    }
  ],
  [
    {
      "font-size": 11,
      "txt": "LAS HEADER"
    },
    {
      "font-size": 10,
      "txt": "~Version ---------------------------------------------------\nVERS. 2.0 : CWLS log ASCII Standard -VERSION 2.0\nWRAP.  NO : One line per depth step\n~Well ------------------------------------------------------\n**STRT.M** 2012-09-16T07:44:12-05:00 : START DEPTH\n**STOP.M** 2012-09-18T08:36:10-05:00 : STOP DEPTH\nSTEP.M                      10.0 : STEP...

[dcslagel]

Hi @dmendres,

Thank you for verifying/confirming that Lasio 0.28.1 resolves the DateTime parsing correctly!

For the issue of writing the Unit incorrectly, I added an addition check in the new test case #420 to verify the unit is correctly 'Datetime'. It still passes. So the issue of the unit reverting to 'M' happens later in the processing. Is LAS2Text.py calling Lasio's write() function?

[kinverarity1]

Seems likely - this code looks pretty dodgy:

lasio/lasio/writer.py

Lines 106 to 127 in 817fb82

	if STRT is None:
	STRT = las.index[0]
	if STOP is None:
	STOP = las.index[-1]
	if STEP is None:
	if STOP != STRT:
	# prevents an error being thrown in the case of only a single sample being written
	STEP = las.index[1] - las.index[0] # Faster than np.gradient
	las.well["STRT"].value = STRT
	las.well["STOP"].value = STOP
	las.well["STEP"].value = STEP
	# Check units
	if las.curves[0].unit:
	unit = las.curves[0].unit
	else:
	unit = las.well["STRT"].unit
	las.well["STRT"].unit = unit
	las.well["STOP"].unit = unit
	las.well["STEP"].unit = unit
	las.curves[0].unit = unit

I've already raised it as an issue for other reasons (#268), but haven't had time to address it.

[dcslagel]

What would you think of creating a separate GitHub issue for this specific unit writing error and closing this issue? It is different enough from the problem this issue started that it will be clearer to track as a separate issue.

Also since it is possible to fix this specific unit writing error without the whole #268 change, so a separate issue from #268 makes sense in that way too.

[kinverarity1]

Agreed, makes sense!