Incorrect date in skew-Ts

[cjnowotarski]

We've noticed when running SHARPpy on real-time research soundings as part of VORTEX-SE that if the sounding is terminated before the synoptic hour, SHARPpy will add "19" instead of "20" as the leading two digits on the time stamp in the skew-T image that is generated. For example, if we finish a sounding at 1150Z but enter 1200Z in the header of the input file and generate the image before 12Z, it will show "19181202/1200" rather than "20181202/1200"

[wblumberg]

Hi @cjnowotarski, I may be able to look into this later on tonight. What version of the program are you using and could you also attach a sample file? I’ll need that to reproduce the problem. Thanks!

[cjnowotarski]

I'm using SHARPpy 1.3.0 on the Anaconda 2.7 distribution of python. A sample file data file is attached. To reproduce the error you would need to set the date or time in the header file to a future date/time, I expect.

-Chris upperair.TAMU_sonde.201812010000.College_Station_TX_SHARPpy.txt

[wblumberg]

Hi Chris,

I just loaded the data using 1.3.0 and our development version and wasn't able to reproduce the issue. However, I took a look at the code, and I have an idea why you may be getting this bug. The decoder has a conditional statement that prevents archived soundings from the 20th century from being read in as if they are from the 21st century. The conditional statement uses the computer clock to check if the sounding is read in as being from the future, and if so forces the data that gets read in to have a date from the 20th century. Is your computer clock set correctly?

Greg

[cjnowotarski]

Yeah, I think that is the issue. Because we're uploading soundings real-time for VORTEX-SE, we are occasionally generating the skew-Ts before the synoptic hour at which they are valid. For example, sometimes we finish a 12Z sounding at 1150Z, thus SHARPpy must default to 1918 since the sounding is technically valid in the future.

-Chris

On Wed, Dec 5, 2018 at 5:45 PM Greg Blumberg notifications@github.com wrote:

Hi Chris,

I just loaded the data using 1.3.0 and our development version and wasn't able to reproduce the issue. However, I took a look at the code, and I have an idea why you may be getting this bug. The decoder has a conditional statement that prevents archived soundings from the 20th century from being read in as if they are from the 21st century. The conditional statement uses computer clock to make sure the sounding isn't read in as being from the future, and can sometimes force the data that gets read in as being from the 20th century. Is your computer clock set correctly?

• Greg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sharppy/SHARPpy/issues/154#issuecomment-444694725, or mute the thread https://github.com/notifications/unsubscribe-auth/ArdsyaPHePX9ugZ-iW_DXK7o3B_zo55Jks5u2Fq0gaJpZM4Y_XV2 .

-- Chris Nowotarski, PhD Assistant Professor Department of Atmospheric Sciences Texas A&M University MS 3150 College Station, TX 77843 610-442-8722

[wblumberg]

Hmm. That could be problematic in other applications, so we'll have to find a way around it. I'm glad you've found this issue and are using the program! You could probably remove the conditional (see line 33) in your local copy, reinstall, and that would probably fix it, just as long as you're not doing anything else with archived data with the same code.

@tsupinie ...can you see any issue with changing line 33 of https://github.com/sharppy/SHARPpy/blob/master/sharppy/io/spc_decoder.py to only be an inequality between the years of the date time objects? I can't think of any scenarios where that might be a big problem.

-Greg

[tsupinie]

I think adding a buffer of an hour would probably be the best way to handle it. I can't think of any potential side effects. Something like this:

if time > datetime.utcnow() + timedelta(hours=1):
    # Do stuff

At some point, SPC is going to have to add the century to the year, and I wish they'd do it sooner rather than later, as that would make this all moot.

[wblumberg]

@tsupinie did we ever include your change in any branch of SHARPpy?

[wblumberg]

We did. Closing.