The commit 3c40366172e3 ("datetime, lua: date parsing functions") introduced a function `datetime.parse()`. The function accepts a datetime format: 'iso8601', 'rfc3339' and a custom datetime format. However, 'iso8601' as well as 'rfc3339' is a set of datetime formats (see [1] and [2]), and `datetime.parse()` supports a subset of these formats. There is a documentation issue [3], where we should describe what formats are supported and what formats are not. The patch adds a tests for most of supported formats. The tests were created using a page about date and time formats in ISO 8601 and RFC 3339 standards [2] and these tests are not exhaustive. More thorough testing can be done with property-based testing and randomization. It will be a subject of the following commits. 1. https://datatracker.ietf.org/doc/html/rfc3339 2. https://ijmacd.github.io/rfc3339-iso8601/ 3. https://github.com/tarantool/doc/issues/3155 Follows up #6731 Needed for tarantool/doc#3155 Co-authored-by: Sergey Kaplun <skaplun@tarantool.org> NO_CHANGELOG=testing NO_DOC=tarantool/doc#3155 (cherry picked from commit dcb196366621db4ab39ef97029ee126d836b77fb)

`datetime` module has a function `:totable()` that converts the information from a datetime object into the table format. The commit 43e10ed34949 ("build, lua: built-in module datetime") added `tzoffset` field to the datetime object and to table produced by `:totable()`. The commit 9ee45289e012 ("datetime: datetime.TZ array") added fields `tz` and `tzindex` to the datetime object, but not to the table produced by `:totable()`. The patch fixes that. Note, `tzindex` is not added, because it is an internal field. ``` tarantool> datetime.parse('2004-12-01T00:00 Europe/Moscow'):totable() --- - tz: Europe/Moscow sec: 0 min: 0 yday: 336 day: 1 nsec: 0 isdst: false wday: 4 tzoffset: 180 month: 12 year: 2004 hour: 0 ... ``` Fixes #10331 Follows up #6751 @TarantoolBot document Title: Support of tz field in :totable() In addition to the `tzoffset` in a table produced by `:totable` we added `tz` field. ``` tarantool> datetime.parse('2004-12-01T00:00 Europe/Moscow'):totable() --- - tz: Europe/Moscow sec: 0 min: 0 yday: 336 day: 1 nsec: 0 isdst: false wday: 4 tzoffset: 180 month: 12 year: 2004 hour: 0 ... ``` (cherry picked from commit 90552e55e0921405c43ea086ae418a72c9f000e4)

This patch fixes a bug found by the ASAN instrumentation of LuaJIT allocator [1]. The problem is using a Lua serializer object that has been cleaned up by GC. The crash occurs when executing `tarantool> \set output lua`. Failing tests: - ./test/app-luatest/gh_7031_configure_eos_in_lua_console_test.lua - ./test/app-tap/console.test.lua - ./test/box/push.test.lua - ./app-tap/console_lua.test.lua - ./app-luatest/varbinary_test.lua The `serializer_lua` static member is removed from `src/box/lua/serialize_lua.c` along with `serializer_lua_init`, because it is not used by any function other than `serializer_lua_init`, which is not needed now too. [1]: Issue #10231 Closes #10177 (this issue is a duplicate of #7404) NO_TEST=rely on existing tests NO_CHANGELOG=codehealth NO_DOC=codehealth (cherry picked from commit 830f27bbaf94dadcacc66a7f543e0e5feec3988d)

To ensure better encapsulation, maintainability, and portability of the code, it is necessary to replace direct access to the fields of global structures with calls using the Lua C API. Closes #10284 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring (cherry picked from commit f7bb3fc7a1222107753dc420675ecda043b0a5d2)

Since commit 8f4be3227635 ("txm: disallow yields after DDL operation in TX"), any DDL operation aborts **all** active transactions, even those that wouldn't be affected by it anyway, see `memtx_engine_prepare()`, `memtx_tx_abort_all_for_ddl()`. Actually, there's no need to do that in Vinyl because it properly handles concurrent DDL operations, see commit d3e123695651 ("vinyl: abort affected transactions when space is removed from cache"). Let's skip Vinyl transactions from consideration by marking the Vinyl engine with a special flag. Closes #10375 NO_DOC=bug fix (cherry picked from commit f5f061d051dc6268949bfcb141d211142282578d)

CMake 3.29.0 produces a warning on configuration stage: NO_WRAP | CMake Warning (dev) in cmake/ProtobufMutator.cmake: | A logical block opening on the line | /home/sergeyb/sources/MRG/tarantool/cmake/ProtobufMutator.cmake:38 (if) | closes on the line | /home/sergeyb/sources/MRG/tarantool/cmake/ProtobufMutator.cmake:40 (endif) | with mis-matching arguments. NO_WRAP The patch fixes the warning. NO_CHANGELOG=build NO_DOC=build NO_TEST=build (cherry picked from commit 1e9e70f4c55c74c94922cb0beef44ae2b82255a9)

An attempt to build Tarantool statically by Ninja (with the enabled CMake option BUILD_STATIC_WITH_BUNDLED_LIBS), error below is produced: | ninja: error: build.ninja:1405: bad $-escape | (literal $ must be written as $$) The commit fixes that error. Follows up commit c92a1699d6c8 ("cmake: support build using Ninja"). NO_CHANGELOG=build NO_DOC=build NO_TEST=build (cherry picked from commit d48c40e69495b8cc3475ea0b184768054d87b780)

CMake 3.24+ produces a warning about the missed option DOWNLOAD_EXTRACT_TIMESTAMP in `ExternalProject_Add()` [1]: | The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy | CMP0135 is not set. Documentation about policy CMP0135 [2] said: CMake 3.23 and below set the timestamps of the extracted contents to the same as the timestamps in the archive. When the URL changes, the new archive is downloaded and extracted, but the timestamps of the extracted contents might not be newer than the previous contents. Anything that depends on the extracted contents might not be rebuilt, even though the contents may change. CMake 3.24 and above prefer to set the timestamps of all extracted contents to the time of the extraction. This ensures that anything that depends on the extracted contents will be rebuilt whenever the URL changes. 1. https://cmake.org/cmake/help/latest/module/ExternalProject.html#url 2. https://cmake.org/cmake/help/latest/policy/CMP0135.html NO_CHANGELOG=build NO_DOC=build NO_TEST=build (cherry picked from commit 4c0e08d85cd39916818bc4b915ac3acdacce8fe4)

After a socket change in the "console.socket" config property and subsequent config reload, Tarantool keeps listening on the old socket. This patch fixes this behavior by properly closing the connection on the old socket on config reload. Closes #9535 NO_DOC=bugfix (cherry picked from commit bb947c101845927803b4b32877f8e6c779b2bca1)

datetime object can be created using `datetime.new()` and `datetime.parse()`. `datetime.new()` sets values of unspecified fields to appropriate values of fields in a Unix time (00:00:00 UTC on 1 January 1971, Thursday), see commit 43e10ed34949 ("build, lua: built-in module datetime"): ``` tarantool> datetime.new() --- - 1970-01-01T00:00:00Z ... tarantool> datetime.new():totable() --- - sec: 0 min: 0 yday: 1 day: 1 nsec: 0 isdst: false wday: 5 tzoffset: 0 month: 1 year: 1970 hour: 0 ``` The function `datetime.parse` converts an input string with the date and time information into a datetime object. When fields are not specified in a input string their values becomes undefined: ``` tarantool> dt.parse('01:01:01', {format ='%H:%M:%S'}):totable() --- - sec: -59 min: -58 yday: 366 day: 31 nsec: 0 isdst: false wday: 1 tzoffset: 0 month: 12 year: 0 hour: -22 ... tarantool> ``` The commit fixes aforementioned behaviour of `datetime.parse()` by setting values for fields not specified by user to values of appropriate fields of Unix time. NO_DOC=bugfix Fixes #8588 (cherry picked from commit 9ac56a1222e916951010091fbdbfc497f4a4971d)