CRHM output file time stamp

[loganxingfang]

I have a list of 15 CRHM model prj runs and used batch run script. These 15 model prj files read 15 obs files and run from 1980 10 1 to 2100 10 1. I attached these 15 model prj files here
Marmot.zip

I attached the batch run script here
MarmotBatchRunScript19802100.zip

The output file CRHM_output_1.obs is not complete; that is, it does not include variables from 1980 10 1 to 2100 10 1. In addition, the time stamp after 2038 01 19 03 00 is not formatted properly, from that point on it is in number array such as 22279112 22279112 111088425 22278712 22278808
See the screen shot here

The rest of output files from CRHM_output_2.obs to CRHM_output_15.obs do include variables from 1980 10 1 to 2100 10 1. However, the time stamp after 2038 01 19 03 00 is not formatted properly, from that point on it is in number array such as 12317576 12317576 479455020 12317176 12317272 in CRHM_output_2.obs
See the screen shot here

I will upload two obs files Marmot_hrly_r8i2p1r1_QDM_combine_1951_2100.obs and Marmot_hrly_r8i2p1r2_QDM_combine_1951_2100.obs to OneDrive folder and will share the link, as they are over file upload limit for gitHub. These two obs files are used by r8i2p1r1.prj and r8i2p1r2.prj, respectively.

For the rest of output files CRHM_output_3 to CRHM_output_15, the issue are the same as that mentioned above. So, fixing the issue for CRHM_output_2.obs would likely resolve issues for other output files.

[jhs507]

I will do my best to take a look at this later this week.

[loganxingfang]

Thanks Justin.

[jhs507]

Sorry for taking so long to get back to you. I have been busy with other work.

I was able to replicate your issue. The fact that the dates stop working in 2038 makes me think this might be a year 2038 problem issue. https://en.wikipedia.org/wiki/Year_2038_problem

This should be possible to fix by compiling for x64 instead of x86 I have been distributing releases in x86 but we should be able to provide both versions. Currently the build configuration for x64 is not correct on visual studio but I should be able to fix it.

[jhs507]

Adding to the likelihood this is the case I ran r8i2p1r1.prj using CRHMcode GCC and was able to get dates up to 2096 (which still doesn't seem complete?)

Here is my output. https://usaskca1-my.sharepoint.com/:u:/g/personal/jhs507_usask_ca/EQ2ebtOeQ91Cpri2d8cgaOMBVRY2ekxKtcz8GTfAZNGckA?e=5VLeLH

[loganxingfang]

Sorry for taking so long to get back to you. I have been busy with other work.

I was able to replicate your issue. The fact that the dates stop working in 2038 makes me think this might be a year 2038 problem issue. https://en.wikipedia.org/wiki/Year_2038_problem

This should be possible to fix by compiling for x64 instead of x86 I have been distributing releases in x86 but we should be able to provide both versions. Currently the build configuration for x64 is not correct on visual studio but I should be able to fix it.

Thanks Justin.

I think this issue would only apply to prj run when specifying timestamp as -t YYYYMMDD for output. For default timestamp as MS data number, it is continuous.

Also, this might be related to this Year 2038 problem. I have batch run for year 2070-2100, and set start and end date as 2070 10 1 and 2100 10 1, respectively. I have the batch script here
MarmotBatchRunScript20702100.zip
I attached one of those 10 prj files for this issue,
r8i2p1r1.zip

In chrmcode, the last time step in the output is 2100 09 30 23:00. While in Borland CRHM, the last time step in the output is 2100 10 1 0:00

[jhs507]

In chrmcode, the last time step in the output is 2100 09 30 23:00. While in Borland CRHM, the last time step in the output is 2100 10 1 0:00

I remember having this off by one difference in the last time step before. I don't know what causes it but I don't think it is related to this particular bug.

I think this issue would only apply to prj run when specifying timestamp as -t YYYYMMDD for output. For default timestamp as MS data number, it is continuous.

This seems to be the case.

[jhs507]

Created a 64 bit version of CRHMcode GUI and I run into an issue on the second hourly timestamp into 09/17/2038 a negative number of -858993461 is passed into StandardConverterUtility::EncodeDateTime as the year variable. This causes an out of bounds array index access. Which would result in the erroneous behavior you see.

The year is set wrong by StandardConverterUtility::DecodeDateTime when the MS date 50665.041666666664 is passed into it.

Not sure exactly what is wrong or what the solution her is but it might have something to do with calling gmtime()