You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Day-of-month validation for #DATE directive is overly simplistic. Walls only checks to make sure day-of-month is <=31. "31" is accepted for months with only 30 days. 29,30 and 31 are accepted for February which has only 28 or 29 days, depending on leap-year.
This issue does not appear to be causing problem within Walls, including date-based magnetic declination calculations.
However, breakage occurs downstream during processing of Walls-exported "shapefiles" if one attempts to cast the survey date into a field type of "date" (the Walls-exported shapefile uses field type of "text", which prevents date-based math). Similar issues may be encountered by other apps which attempt to processes the native Walls .srv files.
Was not able to identify the offending source code.
The text was updated successfully, but these errors were encountered:
Day-of-month validation for #DATE directive is overly simplistic. Walls only checks to make sure day-of-month is <=31. "31" is accepted for months with only 30 days. 29,30 and 31 are accepted for February which has only 28 or 29 days, depending on leap-year.
This issue does not appear to be causing problem within Walls, including date-based magnetic declination calculations.
However, breakage occurs downstream during processing of Walls-exported "shapefiles" if one attempts to cast the survey date into a field type of "date" (the Walls-exported shapefile uses field type of "text", which prevents date-based math). Similar issues may be encountered by other apps which attempt to processes the native Walls .srv files.
Was not able to identify the offending source code.
The text was updated successfully, but these errors were encountered: