# Discrepant results of gmtinfo in GMT 6 and 5 **URL:** \ **Category:** Q&A\ **Created:** [December 26, 2019, 10:48pm UTC](https://forum.generic-mapping-tools.org/t/discrepant-results-of-gmtinfo-in-gmt-6-and-5/156 "2019-12-26T22:48:18Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![trian](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/trian/32/86_2.png) [@trian](https://forum.generic-mapping-tools.org/u/trian)\ **Post date:** [December 26, 2019, 10:48pm UTC](https://forum.generic-mapping-tools.org/t/discrepant-results-of-gmtinfo-in-gmt-6-and-5/156/1 "2019-12-26T22:48:18Z")
Hi all, I have a data file containing earthquake records of the following format: `Year MoDaHrMnSecs Lat Lon Dep M` `2015 0416180744.30 35.1460 26.8880 0.00 6.1 MS` `2015 0416181417.60 35.1280 26.6650 1.50 3.6` `2015 0416182112.50 35.0360 26.6920 0.20 3.8` `2015 0416182354.70 35.1120 26.7660 0.00 3.5` `2015 0416183004.50 35.0190 26.6770 9.60 3.4` `[...]` In order to search the record with the maximum magnitude, I use the command: > gmt info -Eh5 -h1 datafile but the results differ in GMT 6.0.0 (FC 31, fedora yum repo) and 5.4.4 (CentOS 7, epel repo): in 6.0.0: `2015 416180744.3 35.146 26.888 0 6.1 MS` in 5.4.4: `gmtinfo: Mismatch between actual (6) and expected (7) fields near line 3` If I bypass the 7th column with: `sed '2s/ MS\ *$//' datafile | gmt info -Eh5 -h1` I still receive a different output in GMT 5: `2015 0416180744.30 35.1460 26.8880 0.00 6.1` Is there a way to ask from `gmtinfo` not to ignore the leading zero of second column (when it exists), since I need it later to calculate time differences and plot accordingly? Thanks in advance ---
**Author:** ![pwessel](https://yyz1.discourse-cdn.com/flex047/user_avatar/forum.generic-mapping-tools.org/pwessel/32/30_2.png) [@pwessel](https://forum.generic-mapping-tools.org/u/pwessel)\ **Post date:** [December 26, 2019, 11:14pm UTC](https://forum.generic-mapping-tools.org/t/discrepant-results-of-gmtinfo-in-gmt-6-and-5/156/2 "2019-12-26T23:14:28Z")
There are some problems here that are difficult to overcome: First, your time data is not in any ISO-recognizable format [[https://en.wikipedia.org/wiki/ISO\_8601](https://en.wikipedia.org/wiki/ISO_8601)] and hence it is (or cannot be) interpreted as a valid time-stamp. Your time is actually placed across two columns so it is even worse (a time stamp is normally something like yyyy-mm-ddThh:mm:ss.xxxx) It is thus seen as a floating point number and hence to leading 0 is lost in the conversion. You may have software that knows about this particular two-column arrangement but GMT cannot do that. The 5.4.4/6.0.0 difference is tied to a change in the GMT table record format where all text is expected to be in an optional trailing text after all numerical columns. Thus, it does not bother GMT 6 that you have an occasional trailing text (MS) in some records but not in others, but it really bothers GMT 5 who will try to read that MS and obtain 0 or NaN. One workaround would be to awk your file and place the time information into the trailing text. To ensure it is seen as text, maybe print it with a leading T or some other text string, then after you have done your GMT processing you can reformat to whatever final format you need.