3.4 Schema - ComingIntoForceDate Can Not Be In The Future

Apr 25, 2025 by ADMIN 58 views

3.4 Schema - ComingIntoForceDate Cannot Be in the Future

The 3.4 schema of the D-TRO application has a peculiar restriction when it comes to setting the "comingIntoForceDate". This date cannot be set in the future, which may seem counterintuitive at first. In this article, we will delve into the details of this restriction, explore the reasons behind it, and examine the implications of this limitation.

Understanding the Restriction

The "comingIntoForceDate" is a critical field in the D-TRO application, as it determines when a Traffic Regulation Order (TRO) comes into effect. However, when trying to set this date in the future, the application throws an error. This error message indicates that the date cannot be in the future, and provides a specific rule that governs this restriction.

Endpoint Call with Parameters and Body

To better understand the context of this restriction, let's examine the endpoint call with parameters and body. The payload being used is as follows:

{
  "schemaVersion": "3.4.0",
  "data": {
    "source": {
      "actionType": "new",
      "currentTraOwner": 4,
      "provision": [
        {
          "actionType": "new",
          "orderReportingPoint": "ttroTtmoByNotice",
          "provisionDescription": "Crane blocking road - updated 25.3.25 17:29",
          "reference": "163",
          "regulatedPlace": [
            {
              "description": "OS Rome Lea",
              "type": "regulationLocation",
              "linearGeometry": {
                "version": 1,
                "linestring": "SRID=27700;LINESTRING (380899.98 463324.08, 380915.73 463327.12)",
                "representation": "linear",
                "direction": "bidirectional",
                "lateralPosition": "centreline",
                "externalReference": [
                  {
                    "lastUpdateDate": "2025-04-04T15:56:48",
                    "uniqueStreetReferenceNumber": [
                      {
                        "usrn": 9600537
                      }
                    ]
                  }
                ]
              }
            },
            {
              "description": "Diversion via A65, any",
              "type": "diversionRoute",
              "linearGeometry": {
                "version": 1,
                "linestring": "SRID=27700;LINESTRING (380844.09 463306.09, 380843 463305, 380838 463300, 380824 463281, 380816 463273, 380801 463262, 380790 463256, 380784 463254, 380774 463251, 380741.89 463250.62, 380739.8 463250.6, 380724.04 463250.34, 380715.8 463250.2, 380697.8 463247, 380694.79 463246.15, 380693.53 463245.79, 380687.2 463244, 380684.97 463247.51, 380687.2 463244, 380676.8 463237, 380661.2 222.6, 380642.2 463203.6, 380624.6 463184, 380612.6 463164.4, 380601.8 463151.4, 380577.2 463127.6, 380559 463111.2, 380532 463090.2, 380522.56 463081.24, 380520.4 463079.2, 380509 463059.4, 380494.4 463035.6, 380484 463023, 380464 463000.6, 380447 462979.6, 380431.4 462960.6, 380400.6 462923, 380385.6 462905.4, 380375.86 462899.64, 380357.72 462888.91, 380356.35 462888.02, 380357.72 462888.91, 380360 462886, 380364.73 462879.88, 380431 462785, 380466 462739, 380491 462704, 380512 462678, 380546 462640, 380572 462607, 380607 462567, 380611 462562, 380612.38 462560.3, 380611 462562, 380643 462588, 380652 462597, 380658 462604, 380670 462620, 380678 462631, 380681.66 462636.65, 380685 462643, 380692 462660, 380700 462689, 380700 462691, 380709 462738, 380715.8 462771.6, 380728 462825.2, 380735 462857.8, 380746.4 462889.4, 380765 462931.6, 380770.4 462950, 380776.8 462982, 380778 463006.8, 380777 463041.8, 380778.19 463049.9, 380780.4 463065, 380785.4 463088, 380793.8 463113.4, 380804.8 463138.2, 380819 463163, 380825 463172, 380868 463229, 380885.56 463250, 380896.3 463262.84, 380914 463284, 380936 463311, 380943 463321, 380945 463326, 380947 463331, 380943.47 463330.68)",
                "representation": "linear",
                "direction": "bidirectional",
                "lateralPosition": "centreline",
                "externalReference": [
                  {
                    "lastUpdateDate": "2025-04-04T15:56:48",
                    "uniqueStreetReferenceNumber": [
                      {
                        "usrn": 9600537
                      },
                      {
                        "usrn": 9604504
                      },
                      {
                        "usrn": 9600584
                      }
                    ]
                  }
                ]
              }
            }
          ],
          "regulation": [
            {
              "condition": [
                {
                  "timeValidity": {
                    "start "2025-03-25T17:25:37",
                    "end": "2025-03-25T23:59:59"
                  }
                }
              ],
              "generalRegulation": {
                "regulationType": "miscRoadClosure"
              },
              "isDynamic": false,
              "timeZone": "Europe/London"
            }
          ],
          "comingIntoForceDate": "2025-03-30"
        }
      ],
      "reference": "163",
      "section": "All sections",
      "traAffected": [
        4643
      ],
      "traCreator": 4,
      "troName": "Crane blocking road - updated 25.3.25 17:29",
      "madeDate": "2025-04-26",
      "comingIntoForceDate": "2025-04-30",
      "statementDescription": "Crane blocking road - updated 25.3.25 17:29"
    }
  }
}

Error Message from D-TRO Application

The error message from the D-TRO application is as follows:

{
  "ruleError_0": {
    "name": "Invalid 'comingIntoForceDate'",
    "message": "The date that the TRO is coming into force",
    "path": "Source -> comingIntoForceDate",
    "rule": "comingIntoForceDate can not be in the future"
  }
}

Implications of This Limitation

The restriction on setting the "comingIntoForceDate" in the future has significant implications for users of the D-TRO application. This limitation may cause inconvenience and frustration, particularly when users need to set a date in the future for a TRO to come into effect.

Conclusion

In conclusion, the 3.4 schema of the D-TRO application has a peculiar restriction on setting the "comingIntoForceDate" in the future. This limitation is governed by a specific rule that prevents users from setting a date that is ahead of the current date. While this restriction may seem counterintuitive, it is likely intended to prevent users from setting dates that are not yet valid. However, this limitation may still cause inconvenience and frustration for users who need to set dates in the future.
Q&A: 3.4 Schema - ComingIntoForceDate Cannot Be in the Future

In our previous article, we explored the peculiar restriction on setting the "comingIntoForceDate" in the future in the 3.4 schema of the D-TRO application. This limitation has raised several questions and concerns among users. In this article, we will address some of the most frequently asked questions and provide clarification on this issue.

Q: What is the purpose of the "comingIntoForceDate" field?

A: The "comingIntoForceDate" field is used to determine when a Traffic Regulation Order (TRO) comes into effect. This date is critical in ensuring that the TRO is implemented correctly and that the necessary preparations are made.

Q: Why can't I set the "comingIntoForceDate" in the future?

A: The restriction on setting the "comingIntoForceDate" in the future is intended to prevent users from setting dates that are not yet valid. This limitation is in place to ensure that the TRO is implemented correctly and that the necessary preparations are made.

Q: What happens if I try to set the "comingIntoForceDate" in the future?

A: If you try to set the "comingIntoForceDate" in the future, the D-TRO application will throw an error. The error message will indicate that the date cannot be in the future and will provide a specific rule that governs this restriction.

Q: Can I set the "madeDate" in the future?

A: Yes, you can set the "madeDate" in the future. However, there is a validation in place that prevents the "madeDate" from being after the "comingIntoForceDate".

Q: Why is there a validation between the "madeDate" and the "comingIntoForceDate"?

A: The validation between the "madeDate" and the "comingIntoForceDate" is intended to ensure that the TRO is implemented correctly and that the necessary preparations are made. This validation prevents users from setting a "madeDate" that is after the "comingIntoForceDate".

Q: Can I override this validation?

A: No, you cannot override this validation. The validation is in place to ensure that the TRO is implemented correctly and that the necessary preparations are made.

Q: What are the implications of this limitation?

A: The restriction on setting the "comingIntoForceDate" in the future has significant implications for users of the D-TRO application. This limitation may cause inconvenience and frustration, particularly when users need to set a date in the future for a TRO to come into effect.

Q: Can I request a change to this limitation?

A: Yes, you can request a change to this limitation. If you believe that this limitation is causing significant inconvenience or frustration, you can submit a request to the D-TRO application team to review and potentially modify this limitation.

Conclusion