Taking my first stumbling steps in the new (and often wonderful) world of Golang, I have stumbled over a problem formatting time.
Using the format specification below, I expected the date-part of the timestamp to disappear, but no way. I have probably misunderstood the time format altogether, being used to a datetime convention. Here it goes:
import (
"fmt"
"time"
)
func main() {
layout := "15:04:05.00"
str := "19:05:16.88"
t, err := time.Parse(layout, str)
if err != nil {
fmt.Println(err)
}
fmt.Println(t)
// with the layout statement I am expecting to see: 19:05:16.88 +0000 UTC
// but Go happily give me: 0000-01-01 19:05:16.88 +0000 UTC
}
Thank you joncalhoun! That certainly gave me a new insight on formatting in Go! Having said that, I realize i posed the question somewhat unclear - sorry.
I think the problem remains when I’m trying to use the value of “t”, to e.g calculate the difference in time between “now” and this arbitrary time “t” - or will Go take care of that for me?
I guess what it all boils down to: is there a way to get “time-only” (like hh:mm:ss.sss or milliseconds past midnight or something similar) in Go? Your solution elegantly solves the formatting of the output but I am afraid the stored value (in “t”) still contains the date?
Just to give you a background possibly making the problem better defined: The data I have available comes from a GPS-recever and the timestamp sent from the satellites is hhmmss.ss - no date. So, when calculating the difference between the latest sample from the satellite and “now” any date information will screw things up for me.
Note that this will bite you across midnight so you’ll need to handle that, in both directions depending on which way your clock is off. Maybe just assume that the clock difference will always be less than 12 hours, not much more you can do if you don’t have a reference date on the other side.
(To nitpick, the GPS signal certainly has date information in it. It may not be sent over the interface you are looking at though.)
Thank you, Jakob. Yes it is reasonable that times have a date since, as you say, it represents a point in time and without a date it reduces to a point within any random day. So I’ve better include the date in the timestamps. The problem around midnight seems pretty straightforward to take care of.
Thanks to both of you for setting it straight for me.
As a side note: Regarding the GPS format, it is a bit strange but the NMEA-0183 standard actually do not use dates in general, only UTC time. E.g. the G+GGA and G+GNS messages (containing the lat/long-info I’m using) only specifies UTC formatted as hhmmss.ss which is pretty strange. In order to get the satellite’s date, I have to use e.g G+ZDA. No big deal, but as my application is keeping track of what my motorcycle (and myself) is doing on the racetrack, I sample the GPS at as high rate as possible (here 10HZ) and doing a lot of math on signals from other sensors like accelerometers, magnetometers, RTK and others to gain high precision also at speeds above 250km/h. So I’m trying to reduce the amount of data as much as possible.
That sounds like a really cool use case. I guess the offset between the GPS reported time and your system clock will be small enough that this shouldn’t be an issue. And if you’re in a European time zone and not a night rider you can get away with not handling the midnight issue.
Night riding is certainly not within the use case - I assure you There is a number of challenging issues (at 250km/h I’m traveling ~70m/s) like obtaining a system-wide resolution of less than 1m. The best system clock I have available would certainly be the GPS data, they tell me they are pretty accurate Hence, I am using the GPS’s clock as a system clock that all other sensors are referring to. I think this use case will be a challenge for the Go concurrency even if the system is running on a Rock64. As a consequence, even if I process some of the sensor fusion in hardware, I will need to optimize the code for speed and concurrency.
I guess the offset between the GPS reported time and your system clock will be small enough that this shouldn’t be an issue. And if you’re in a European time zone and not a night rider you can get away with not handling the midnight issue.
Hence, I am using the GPS’s clock as a system clock that all other sensors are referring to. I think this use case will be a challenge for the Go concurrency even if the system is running on a Rock64. As a consequence, even if I process some of the sensor fusion in hardware, I will need to optimize the code for speed and concurrency.