Parsing of Time in HTTP POST ?
I have been using "YYYYMMDDhhmmss" format for date without any problem.
Now because the same device should send data to two different Host I have to move to the UTC format (millis seconds from 1, 1, 1970).
I experienced bad parsing of the timestamp while the same string is correctly parsed by a Web UTC -> Date string application.
Can anyone explain exactly how such timestamp should be formatted for Mango :
- 1231233112. (decimal point)
- 1231233112000 (no decimal point)
Thanks in advance for your assistance.
I've never tried it this way but dates in Mango are generally milliseconds so like 1231233112000 would be the way to represent a Unix type timestamp in Mango.
It doesn't work that way.
Mango is replacing the timestamp with the server one as if there were no timestamp in the POST.
When publisher sends data out it looks like the timestamp is like "123245654.1123" with a decimal point (I see that on the
This is what I do in the Gateway :
Format the number of seconds since Epoch, adding 3 x '0' at the end. :
snprintf(WorkBuffer, sizeof(WorkBuffer), "%ld000;", ModbusTimestamp);
This the resulting POST contents :
POST /httpds HTTP/1.1
This is what is decoded by Mango :
Device ID: PGP_001EC01EF773
In this case Mango hase tried to interpret the timestamp creating a date with 1441 as the year.
It sounds like the HTTP receiver is not designed to use a Unix style time. We can look at this and see if it's something we can add.
I tried also adding a decimal point :
This is the result (The time displayed is the server time because the 4 successive POSTs sent are "dated" with 1 second delay between each of them instead of 15" as the timestamp sent be the Gateway specifies) :
Device ID: PGP_001EC01EF773
You were using the correct format in your example post: __time=1441120275000
I just ran a few tests and did some debugging. I found a bug where the code was first converting the __time parameter via the 'yyyyMMddHHmmss' format, since the timestamp actually does translate into a valid date it was returning this.
I have fixed this bug in the 2.6.0 Core and just pushed out a new version of this module for the 2.5.2 core, the new module version is 1.4.8 and you should be able to do an automatic upgrade from the modules page if you are on Core 2.5.2 or later.
The new logic will first convert the value using the 'yyyyMMddHHmmss' format and then compare the date. If the data is before Jan 1 1970 then it will try the other formats. In your case the proper time is then used.
Thank you !
Keep in mind that in 2032 the timestamp will start with 1970.... and the decoded year will be > 1970.
After testing the updated version, it looks like there is a difference of 1 hour between the time decoded by Mango from "YYYYMMDDHHMMSS" and the UTC timestamp.
The first one is correct and the seconde one is 1 hour later ?
I have tried both and it is not correct.
Any clue ?
Thanks for the note on the 2032 problem, if you are still using this module in 2032 I'll give you a free enterprise license to Mango with an upgraded module!
As for the 1 hour off problem, could it be a timezone problem? Is there a 1hr time difference between where your Mango server is vs where the http request is coming from? Mango will parse the UTC timestamp into a date using its local timezone. Then of course there is the User's timezone that will re-convert the timestamps into a Date when viewed through Mango.
One way to confirm this would be to check the ts column for the data point in the pointValues table. It should match exactly what you are sending through.
I will check but what looks strange to me is that I tried sending the same date+time in the 2 formats and one was correctly received the other one, with a difference of 1 hour.
If you still can't make sense of it just send me the strings you used for both formats, I can check them against my test Mango.