Wrong timestamp on incoming case report

[karolikl]

The Darth Vader case report was sent on April 4th around 22:00, but the timestamp says April 5th at 12:00.

[einari]

On the ingress for SMS Eagle the timestamp seems right:

{"timestamp":"2018-04-04T20:09:37.6503919+00:00","source":null,"correlationId":"00000000-0000-0000-0000-000000000000","level":"info","message":"[Receive(45)]-{\"Id\":\"e11f7aff-769e-449a-9f72-5c4a47fce726\",\"Sent\":\"2018-04-04T22:09:37+00:00\",\"OriginNumber\":\"+47-------\",\"Message\":\"12\",\"Keyword\":null,\"FullMessage\":\"12\",\"ReceivedAtGatewayNumber\":\"1\"}","method":"[Unknown]","line":0,"content":{"sourceContext":{"value":"IncomingController"},"actionId":{"value":"4f180a93-5175-467c-b574-0762af4aa53e"},"actionName":{"value":"Web.IncomingController.Receive (Web)"},"requestId":{"value":"0HLCB9EBEJEGI:00000001"},"requestPath":{"value":"/incoming"}}}

[Velcrow81]

@einari : I sent the 'Darth Vader' message at 21:59 norwegian time, so I would expect the time from sms eagle to be around 20.00 UTC. I see that there are two time values in the message. "timestamp":"2018-04-04T20:09:37.6503919+00:00" and "Sent\":\"2018-04-04T22:09:37+00:00\". It is only Sent that is available on the event TextMessage and that is used in the reports. Since that has the wrong value (two hours too much in UTC), the value will be a little over midnight norwegian time. So the problem is not in UI, but before the values are recieved in VR.

1. How is the Sent value set and why is it different from timestamp?
2. Both Sent and Timestamp are in UTC time but differ with two hours. Why?
3. I sent the message at 21:59 norwegian time and it seems like it took ten minutes before the message was recieved. Is that correct? Should it be that slow?

It seems there is some timezone issue in the code that handles sms before the TextMessage event is processed in the VR bounded context. Ideas?

[einari]

Good catch!

The timestamp at the beginning is actually the logging timestamp - so not the timestamp coming from the SMS Eagle at all. However, the Sent value is the one coming from the SMS Eagle - but it does not have timezone information in it - so I'm suspecting a fair amount of naivety in the following code:

Sent = DateTimeOffset.ParseExact(sms.Timestamp,"yyyyMMddHHmmss", System.Globalization.CultureInfo.InvariantCulture),

This needs to do things differently. Since its probably defaulting to be a UTC time - no offset, it obviously now with daylight saving- summertime effective, it means it will be 2 hours more and crossing midnight.

Very good thing we got to test this at that time, it wouldn't have been that obvious if we just tested at day time.

Time to pull in NodaTime perhaps..

If you want to have a look, the code is in the IncomingController in the ./Source/SMS/SMSEagle folder.

If not, you can assign the issue to me.

Alternatively, the answer on this SO post looks interesting. Basically adding TimeZone info into it.

[Velcrow81]

We need to know the offset of the contry were a messages originated from and that is not possible as the code is now. Is it possible to get the SMS eagles to report timestamp with offset according to the contry it is placed in? Or do we have to check witch country a device is located in and then add the offset according to this country? Should that perhaps be part of some configuration for each device in admin or something? For the MVP we could default to norwegian time, but that will obviously not work globaly

[einari]

The eagle is fixed for the HTTP request it does and can't see any way of customizing it. But we could make it configurable - meaning that we can have each box report to a URL that makes it possible to identify it's origin and then have configuration in the cloud that has the Timezone and adjust the sent time accordingly

[eprom]

I liked that @einari. If I recall correctly, Eagle can be set with API key which can unique identify Eagle. The key then can be mapped with a time zone and other stuffs.

[einari]

That's a good point @eprom - holding the info in that key and just generate it during provisioning of the device. I was thinking of storing it in Azure and just look it up - but this is much better!

[Velcrow81]

Proposed initial solution is to send a guid from sms eagle and have a hard coded list with corresponding timezone. In the future, this should be configurable per country

[karolikl]

Still getting the wrong timestamps (-2 hours)

[Velcrow81]

@einari : What is the status on this? Should each tenant be configured to run in its correct timezone and when an eagle text is routed into a tenant, the timezone will be correct when the timestamp is created. How should tenants be set up/initialized? Selecting a timezone and possibly culture etc should perhaps be part of this?

[einari]

This whole thing should be planned out much more. It would be perfect to do an event storming on this. There are timelines and processes here and multiple aspects.

At the codeathon we should have a team just working with SMS and we could kick off it all with an event storming around everything related and then create the relevant issues.

[Velcrow81]

Sounds like a plan :)

[esp0]

@Velcrow81 This Issue is marked as "In Progress" in the Reporting BC. Should it be moved back to the backlog until the specification is ready?

[Velcrow81]

Yes 😊

tor. 11. apr. 2019, 08:25 skrev Espen Johnsen notifications@github.com:

@Velcrow81 https://github.com/Velcrow81 This Issue is marked as "In Progress" in the Reporting BC. Should it be moved back to the backlog until the specification is ready?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/IFRCGo/cbs/issues/594#issuecomment-481982556, or mute the thread https://github.com/notifications/unsubscribe-auth/AVDCu16J_9EjklJWUYSwEeB02q5S0ISuks5vftU9gaJpZM4THayk .