This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Stefan Sperling gerrit-no-reply at lists.osmocom.orgStefan 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 <stsp at stsp.name> Gerrit-Reviewer: Jenkins Builder (1000002) Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-Reviewer: Stefan Sperling <stsp at stsp.name> Gerrit-CC: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Comment-Date: Fri, 07 Dec 2018 11:04:36 +0000 Gerrit-HasComments: Yes Gerrit-HasLabels: No -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181207/d1f9ea20/attachment.htm>