From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 9D7596EC40; Thu, 19 Aug 2021 14:53:18 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9D7596EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1629373998; bh=72N4K4ytpz/1p+P9KhZIyRjJlHbb4r1sIuLz04aXLPk=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=QKbc+P6oMdsJHy45ZzzTjsmAvcE4Acprw2E52C/ov/5k76w9C7dOvN6EWgpkkJ7bn KWDROWvhDgG4D1yHzN1aNI31Bwmkc77iffrRux+JrtTlwuSpciho0B3s+5d7yNt2ig x8fX2Fmn/hqLPxm+R/wb7wH0ZbTHA8unNnL1w56E= Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 384C16EC40 for ; Thu, 19 Aug 2021 14:53:17 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 384C16EC40 Received: by smtp46.i.mail.ru with esmtpa (envelope-from ) id 1mGgbj-00022S-CO; Thu, 19 Aug 2021 14:53:15 +0300 To: unera@tarantool.org References: <1e9be2a14c934c0597c519a3cb72f30e2ce9e76a.1629341071.git.tsafin@tarantool.org> <1629371897.227277377@f106.i.mail.ru> Message-ID: Date: Thu, 19 Aug 2021 14:53:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <1629371897.227277377@f106.i.mail.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD910164DC12A5633065676A9727AC27C74182A05F53808504023C28CB0CA9ECB5EF48D801E7B0D04FF35856D9EFB0962E29F65B2BDB6630576 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE712EB008F780777E9EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006378D70459430292EC88638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8A8A69F77CE9E676EB8B879DD8ED92A6E117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC2EE5AD8F952D28FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE41BF15D38FB6CB3A49AF716F719AB83ED8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE367F1C1C3ABB44F3A6E0066C2D8992A16C4224003CC836476EA7A3FFF5B025636E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F79006377870F476E0DB9443EFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A213B5FB47DCBC3458834459D11680B505174D7B233CC048AA30D7E4B9E178252E X-C1DE0DAB: 0D63561A33F958A5EB9C17D34B1E49328B1F849926064195A1072CAA8FF215D7D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA758B25CD4253D1D611410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F7CC4EA888783AE0D15634750134FCA683AFE04C49FDBABD2DC6723529F6DF0DF57053C6393067741D7E09C32AA3244CE4C3DFA6B3326C4C7EE0A6297EBB81BD64EE5813BBCA3A9D83B48618A63566E0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojGSxK+6r6oBE+cCtKZvTW1A== X-Mailru-Sender: 6CA451E36783D721CBEA96CEA26D325D68BB47F7815FD216C9C567949FE754B3B7CBEF92542CD7C82F97C478340294DCC77752E0C033A69E0F0C7111264B8915FF1320A92A5534336C18EFA0BB12DBB0 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v6 3/5] box, datetime: datetime comparison for indices X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Safin Timur via Tarantool-patches Reply-To: Safin Timur Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On 19.08.2021 14:18, unera@tarantool.org wrote: > Hi! > I looked trhough the patchset. > I also compiled the bracnch and tested by hand. > Example: > tarantool> datetime = require('datetime') > --- > ... > tarantool> datetime.new('2020-01-02 02:00') > --- > - 1970-01-01T00:00Z > ... > tarantool> datetime.new('2020-01-02 02:00+0300') > --- > - 1970-01-01T00:00Z > ... > tarantool> datetime.new('2020-01-02 02:00:11+0300') > --- > - 1970-01-01T00:00Z > ... > tarantool> datetime.new('2020-01-02T02:00:11+0300') > --- > - 1970-01-01T00:00Z > ... > The code looks like as broken. Not exactly :) .new{} is constructor which is not expecting string at the moment. .parse() expect strings, or defaul __call handler for the module, which is dispatching between parsing, if passed string, and, direct calling constructor, if there are no arguments passed or they are object. ``` tarantool> date('2020-01-02 02:00') --- - 2020-01-02T02:00Z ... tarantool> date('2020-01-02 02:00') --- - 2020-01-02T02:00Z ... tarantool> date('2020-01-02 02:00:11+0300') --- - 2020-01-02T02:00:11+03:00 ... tarantool> date('2020-01-02T02:00:11+0300') --- - 2020-01-02T02:00:11+03:00 ... ``` > Also my notes: > > 1. tostring has to return datetime string with seconds and timezone Will add required seconds - they are reduced now for more compact form like here below. ------------------------------------------------ if (second || nanosec) { SNPRINT(sz, snprintf, buf, len, ":%02d", second); if (nanosec) { ------------------------------------------------ here is incrementa change which enforce required seconds: ------------------------------------------------ diff --git a/src/lib/core/datetime.c b/src/lib/core/datetime.c index ebc05e29c..6e2a76da5 100644 --- a/src/lib/core/datetime.c +++ b/src/lib/core/datetime.c @@ -93,20 +93,17 @@ datetime_to_string(const struct datetime *date, char *buf, int len) nanosec = date->nsec; int sz = 0; - SNPRINT(sz, snprintf, buf, len, "%04d-%02d-%02dT%02d:%02d", - year, month, day, hour, minute); - if (second || nanosec) { - SNPRINT(sz, snprintf, buf, len, ":%02d", second); - if (nanosec) { - if ((nanosec % 1000000) == 0) - SNPRINT(sz, snprintf, buf, len, ".%03d", - nanosec / 1000000); - else if ((nanosec % 1000) == 0) - SNPRINT(sz, snprintf, buf, len, ".%06d", - nanosec / 1000); - else - SNPRINT(sz, snprintf, buf, len, ".%09d", nanosec); - } + SNPRINT(sz, snprintf, buf, len, "%04d-%02d-%02dT%02d:%02d:%02d", + year, month, day, hour, minute, second); + if (nanosec != 0) { + if ((nanosec % 1000000) == 0) + SNPRINT(sz, snprintf, buf, len, ".%03d", + nanosec / 1000000); + else if ((nanosec % 1000) == 0) + SNPRINT(sz, snprintf, buf, len, ".%06d", + nanosec / 1000); + else + SNPRINT(sz, snprintf, buf, len, ".%09d", nanosec); } if (offset == 0) { SNPRINT(sz, snprintf, buf, len, "Z"); ------------------------------------------------ > 2. also the other databases try to avoid to use «Z» symbol in > datetime-format, so I thing we should use «+00:00» instead «Z» I don't care which way to output UTC, but here I need more examples (which vendor, how and when outputs timezone)... Like - here is DATE WITH TIMEZONE column, and here is DATE WITHOUT TIMEZONE. And here TIMESTAMP WITHOUT TIMEZONE, and with UTC, and we see... > > Yesterday we approved the following API: > T:add{year=XXX, month=YYY, ...} > T:sub{year=XXX, month=YYY, ...} > T:set{year=XXX, …, tz=’+03:00’} > T:strftime(‘%F %D %z’) > I want to see a test set for the API. FWIW, :add{}/:sub{}/:strftime{} are there, but not :set() as unimplemented yet. > > Also we approved the following methods: > T:sec() — 35 > T:min() — 12 > T:day() — 19 > T:wday() — 5 > T:yday() — 231 > T:year() — 2021 > T:month() — 8 > T:hour() — 23 > T:tz() — ‘+03:00’ Those have not yet been exported, yes. And BTW, tz() assumed to return numeric information (difference in minutes to UTC), not string representation? What about :totable() - I've got an impression that we also approved it. Yes? > It would be nice to see test set for each of the functions. > Also it would be nice to rename ambigouos items «secs» to «epoch» or > «timestamp» Here I am confused - which "items" do you mean here? [Internal strcuture fields, or some API elements?] > Datetime object must have methods to return integer and float timestamp: > T:epoch() > T:timestamp() epoch() is integer, and timestamp() is double, correct? > > Четверг, 19 августа 2021, 5:58 +03:00 от Timur Safin via > Tarantool-patches : > * storage hints implemented for datetime_t values; > * proper comparison for indices of datetime type. > > Part of #5941 > Part of #5946 > > @TarantoolBot document > > Title: Storage support for datetime values > > It's now possible to store datetime values in spaces and create > indexed datetime fields. > > Please refer to > https://github.com/tarantool/tarantool/discussions/6244 > > for more detailed description of a storage schema. > > -- > Dmitry E. Oboukhov Thanks, Timur