• After witnessing the continued decrease of involvement in the SpotterNetwork staff in serving SN members with troubleshooting issues recently, I have unilaterally decided to terminate the relationship between SpotterNetwork's support and Stormtrack. I have witnessed multiple users unable to receive support weeks after initiating help threads on the forum. I find this lack of response from SpotterNetwork officials disappointing and a failure to hold up their end of the agreement that was made years ago, before I took over management of this site. In my opinion, having Stormtrack users sit and wait for so long to receive help on SpotterNetwork issues on the Stormtrack forums reflects poorly not only on SpotterNetwork, but on Stormtrack and (by association) me as well. Since the issue has not been satisfactorily addressed, I no longer wish for the Stormtrack forum to be associated with SpotterNetwork.

    I apologize to those who continue to have issues with the service and continue to see their issues left unaddressed. Please understand that the connection between ST and SN was put in place long before I had any say over it. But now that I am the "captain of this ship," it is within my right (nay, duty) to make adjustments as I see necessary. Ending this relationship is such an adjustment.

    For those who continue to need help, I recommend navigating a web browswer to SpotterNetwork's About page, and seeking the individuals listed on that page for all further inquiries about SpotterNetwork.

    From this moment forward, the SpotterNetwork sub-forum has been hidden/deleted and there will be no assurance that any SpotterNetwork issues brought up in any of Stormtrack's other sub-forums will be addressed. Do not rely on Stormtrack for help with SpotterNetwork issues.

    Sincerely, Jeff D.

Bufkit date issue starting on July 1st 00z data and beyond.

Joined
May 26, 2009
Messages
43
I'm running Bufkit and never had issue until some of the models starts to get data starting on July 1st.

EX: if i look at the GFS for Monday June 30th 4:00 pm (21z), the date (bottom right) is showing it correctly. Then if i move to the next period, the date is showing as Monday January 6th 7:00 pm (00z) - as if the month and the day have been reversed.

I started to get that with GFS data, thinking it was a bad run - i didn't mind.. But now that other models are reaching the same period of time, they too are showing the wrong date. I looked at the data itself and the TIME = is formated the same way before or after that period - so it's not the data, but Bufkit itself.

Is anybody getting the same issue ? Any feedback will help .

P.S. if it was my desktop config, i think i would have the same problem all year long - but the issue is only showing with timestamp data starting on July 1st 00z and beyond.

Picture of the issue :
http://www.reggphotos.com/tphoto/dateok1.png
 
Last edited by a moderator:
I just tried with an older version (10.6) and i don't get the behavior.. Seems the issue is with newer versions - i just sent a note to NOAA WDTB. I'll post the answer (if any).
 
Last edited by a moderator:
I'm not seeing the problem with the latest version of Bufkit on a Win7 PC. Perhaps a locality issue, i.e. the way that Bufkit reads dates from localities other than the U.S.? Of course that doesn't explain why it breaks for you on the crossover from June to July. There was a fix for the "Adjust Local Time" capability in 13.4, but once again, why the June to July problem? Strange.
 
Got the answer from NOAA WDTB - the issue is with the language setting of the PC itself. It's working fine with English (Canada or US), but gives the issue if using another language (my case). For a reason to be determined, it only affects timestamps from july 1st 00z and beyond, and not the ones prior to that timestamp.

Thanks for the feedbacks.
 
Last feedback from NOAA WDTB office.

They now have a documented issue to fix for an upcoming version. Temporary fix or workaround is to set the PC to English (Canadian or US).

Case closed for me.
 
Back
Top