feat: timestamps back to FDSN format for api query parameter and result#273
Merged
feat: timestamps back to FDSN format for api query parameter and result#273
Conversation
junghao
force-pushed
the
timezone-rollback
branch
4 times, most recently
from
04a489e to
a2a7de6
Compare
junghao
force-pushed
the
timezone-rollback
branch
2 times, most recently
from
8ddc8ab to
d2b2f18
Compare
wilsonjord
reviewed
Oct 24, 2025
cmd/fdsn-ws/fdsn_event.go
Outdated
Comment on lines
575
to
571
| s := fmt.Sprintf("%s|%s|%.3f|%.3f|%.1f|GNS|GNS|GNS|%s|%s|%.1f|GNS|%s|%s\n", eventID, tm.UTC().Format(time.RFC3339Nano), latitude, longitude, depth, eventID, magType, magnitude, loc, eventType) | ||
| s := fmt.Sprintf("%s|%s|%.3f|%.3f|%.1f|GNS|GNS|GNS|%s|%s|%.1f|GNS|%s|%s\n", eventID, tm.Format(fdsn.WsMarshalTimeFormat), latitude, longitude, depth, eventID, magType, magnitude, loc, eventType) |
There was a problem hiding this comment.
question: is tm in this scenario already UTC? If tm is localtime, would you get difference results?
Contributor
Author
There was a problem hiding this comment.
Though it's unlikely but since we called UTC() previously, we should keep doing it.
cmd/fdsn-ws/fdsn_station.go
Outdated
Comment on lines
801
to
802
| if v.StartTime != fdsn.ZeroWsDateTime { | ||
| st := v.StartTime.Time |
There was a problem hiding this comment.
suggestion(non-blocking): if you like oneliners: if st := v.StartTime.Time; v.StartTime != fdsn.ZeroWsDateTime {
cmd/fdsn-ws/fdsn_station.go
Outdated
Comment on lines
819
to
820
| if v.EndTime != fdsn.EmptyWsDateTime { | ||
| et := v.EndTime.Time |
There was a problem hiding this comment.
suggestion: can be one line, see above
…lt. Only StationXML uses new RFC3339
junghao
force-pushed
the
timezone-rollback
branch
from
e3c2fb9 to
418be0f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously we deployed in prod
#269
#270
#272
and caused services like shaking layer getting errors, so we rolled back in an hour.
After more detailed clarification https://github.com/orgs/GeoNet/projects/37/views/27?pane=issue&itemId=133985258&issue=GeoNet%7Ctickets%7C18946, the conclusion be:
Only StationXML 1.2 adopts RFC3339 time format. and all other endpoints/responses still using old FDSN format time (similar to RFC3339, but without timezone info).
In this PR, I split the timestamp into two implementations, one for general FDSN use, one specifically for StationXML use.
Deployed in http://tf-dev-fdsn-web-1308277073.ap-southeast-2.elb.amazonaws.com.
====
Last failed deployment resulted in ShakingLayer-api having errors like
I ran shaking layer api locally by pointing FDSN to the updated dev instance and it works without errors.