Hi Denis, sorry but it make no sense to me. If Kannel send absolute time format than SMSC can do whatever it want with it, recalculate to local time etc. Absolute time is not afffected if you are moving between TZs.
Alex > Am 19.07.2018 um 15:25 schrieb Денис Давыдов <dyna...@gmail.com>: > > Alex, > > Thanks for the answer. > > Firstly, the set of different validity_period is a requirement in our > business workflow. Secondly, our ESMEs is geographically in different TZs and > they are movable objects and we don't know ESME's location at the time of > sending the message. In this case our SMPP provider recommends us to use the > relative time format, because of the end provider's equipment that > interacting with ESME works in accordance with local time zone (it is verify > validity_period in it's retry sending schemes as I was informed). > > -- > Kind regards, > Denis > > > чт, 19 июл. 2018 г. в 12:18, <amal...@kannel.org <mailto:amal...@kannel.org>>: > Hi, > > tha first question would be, why do you want to keep it in relative time > format? > As answer to your question: no this is not possible now , because Kannel > converts > timestamp to unix timestamp internally on the input side and afterwards to > absolute > time format. Sure you make changes to the source code to send relative time > format… > > Thanks, > Alex > > > Am 19.07.2018 um 08:51 schrieb Денис Давыдов <dyna...@gmail.com > > <mailto:dyna...@gmail.com>>: > > > > Hi all, > > > > Is there a possibility to keep validity_period of MT which sending from > > opensmppbox to external SMSCs in the relative time format unchanged? For > > now, I see the kannel changing it to the absolute time format. > > > > For example, this is a snippet from the opensmppbox logfile (this was a > > submit_sm where is the vp was set to 1 minute): > > > > 2018-07-17 10:57:20 [29721] [421] DEBUG: validity_period: > > "000000000100000R" > > > > That is a snippet from SMSC log: > > > > 2018-07-17 10:57:20 [2565] [25] DEBUG: SMPP PDU 0x7fe864004010 dump: > > 2018-07-17 10:57:20 [2565] [25] DEBUG: type_name: submit_sm > > 2018-07-17 10:57:20 [2565] [25] DEBUG: command_id: 4 = 0x00000004 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: command_status: 0 = 0x00000000 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: sequence_number: 225108 = > > 0x00036f54 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: service_type: "CMT" > > ... > > 2018-07-17 10:57:20 [2565] [25] DEBUG: esm_class: 3 = 0x00000003 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: protocol_id: 0 = 0x00000000 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: priority_flag: 1 = 0x00000001 > > 2018-07-17 10:57:20 [2565] [25] DEBUG: schedule_delivery_time: NULL > > 2018-07-17 10:57:20 [2565] [25] DEBUG: validity_period: "180717105820000+" > > > > For me the goal is to keep relative time format keep unchanged while > > message leaves the kannel. > > > > Any feedback is appreciated. Thanks! > > > > -- > > Kind regards, > > Denis >
