Stefan Sperling has posted comments on this change. ( 
https://gerrit.osmocom.org/12121 )

Change subject: store timestamp of last location update seen from subscriber
......................................................................


Patch Set 5:

(4 comments)

https://gerrit.osmocom.org/#/c/12121/5//COMMIT_MSG
Commit Message:

https://gerrit.osmocom.org/#/c/12121/5//COMMIT_MSG@11
PS5, Line 11: in the 'subscriber' table, in granularity of seconds.
> (imho what the value means should be in a code comment and not so much in a 
> commit log)
The value is indeed UTC.

The conversion from local time to UTC is done by SQlite.
I wrote a patch to convert to UTC in our C code, but with that patch the 
conversion happens twice, so I had to discard this patch.
Instead I have added a comment which documents what SQlite will do with the 
timestamp.


https://gerrit.osmocom.org/#/c/12121/5//COMMIT_MSG@19
PS5, Line 19:   901990000000001|2018-12-04 14:17:12
> I wonder why we don't store it as num of seconds since 1970. […]
Our code only deals with seconds since epoch.

SQlite is transforming from seconds since epoch to a string.
The reverse transformation can probably be done by SQlite as well; if not, we 
could easily do it in C.

I think storing the time as a string is great for users because an epoch 
timestamp is meaningless to humans.
It also makes future VTY timestamp display trivial (just print a string).


https://gerrit.osmocom.org/#/c/12121/5/sql/hlr.sql
File sql/hlr.sql:

https://gerrit.osmocom.org/#/c/12121/5/sql/hlr.sql@42
PS5, Line 42:   last_lu_seen TIMESTAMP default NULL
> found https://www.sqlite.org/lang_datefunc. […]
I also noticed that documentation seems to be lacking here.
My tests are producing good results though.


https://gerrit.osmocom.org/#/c/12121/5/src/db_hlr.c
File src/db_hlr.c:

https://gerrit.osmocom.org/#/c/12121/5/src/db_hlr.c@637
PS5, Line 637:                 "Cannot update LU timestamp for subscriber 
ID=%"PRId64": SQL error: (%d) %s\n",
> Be careful in general with interleavin strings and PRId64 type of strings, I 
> recall seeing compilers […]
This problem also affects many other existing strings in this file.
So I would defer this to a separate patch.



--
To view, visit https://gerrit.osmocom.org/12121
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-hlr
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ibeb49d45aec18451a260a6654b8c51b8fc3bec50
Gerrit-Change-Number: 12121
Gerrit-PatchSet: 5
Gerrit-Owner: Stefan Sperling <[email protected]>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Pau Espin Pedrol <[email protected]>
Gerrit-Reviewer: Stefan Sperling <[email protected]>
Gerrit-CC: Neels Hofmeyr <[email protected]>
Gerrit-Comment-Date: Fri, 07 Dec 2018 11:04:36 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No

Reply via email to