Added implementations to the set-timezone step, fixed attribute and v…

[shiladitya-mukherjee]

…alue parsing for datetime fields in AttributeMatcher and ValueMatcher

For the title of this PR: please follow the grammatical rules of a usual publication title, without capitalisation (except for the first letter). Thus, the title should NOT CONTAIN CODE: no dots, no parentheses, no backticks, no brackets, etc. It needs to be distinctive (not detailed) and succinct (not lengthy). Details of this PR will go in the description. For the description of this PR: please replace every line in curly brackets ( { like this } ) with an appropriate description following the guidance. Finally, please remove this paragraph.

What is the goal of this PR?

{ In the form of a paragraph (only use bullet points if strictly necessary), please describe the goal of this PR, why they are valuable to achieve, and reference the related GitHub issues. This section will be automatically compiled into the release notes, so please:

• describe the impact of the change in this PR to the user of this repository (e.g. end user, contributor, developer).
• describe the new product behaviour in present tense, and the old behaviour and how it's been changed in past tense.
• Use the Royal We: "We" made changes, not "I" made changes. }

What are the changes implemented in this PR?

{ Please explain what you implemented, why your changes are the best way to achieve the goal(s) above. Please describe every method, class and package, by explaining:

• its responsibility,
• how it's expected to behave, and
• how it relates to the adjacent methods/classes/packages it interacts with.

This would allow the reviewer to understand your intentions in the code much better. If you're adding new classes, make sure these explanations are also included in the class header comments. Last but not least, please reference the GitHub issues to be automatically closed, such like 'closes #number'. }

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.