Hello Panthéa,

I apologize for the delayed response.

Hello Panthéa,

I wanted you to add "CET" as the timezone in your data. My hope there was that the system would just opt to use the timezone specified by the input file. But since it seems to use "CEST" regardless I don't think this will help. We actually opened up a bug for this which you can follow here https://www.labkey.org/home/Developer/issues/issues-details.view?issueId=41109.

After discussing this with Molly who spent some time on this issue, we think that including support for “CEST” still may not resolve the issue. We think that it may have more to do with how the date is being parsed. By that I mean whether your system is set to use “U.S date parsing” or “Non-US date parsing”. You can find this setting in Labkey under the Admin console → Look and feel settings. Our theory is that perhaps the parsing setting is not set appropriately for the data in the file. For example, if you are testing with files from our tutorials that assume US date parsing while you have Non US parsing set you will likely run into issues. To test this could you change your “Look and Feel” settings to use US based parsing and try out the tutorials files again? Be sure to change the setting back when you are done testing.

The reason you are seeing differences between the demographics file versus the LabResults is because the demographics file only contains one date 02/02/2020 which is the same if you were to parse it using US settings or even European settings. The LabResults file contains a range of future dates that may not be able to be parsed either way like the date in the demographics file.

Another strategy is to eliminate the complications of using the Excel/.xls file formatting - Excel may be displaying dates one way but the underlying date code might still be wrong. To eliminate this, you could use text files instead. For example, the attached .csv file contains the same data as the LabResults file attached to our tutorial, but formatted as comma separated values, essentially forcing 'year-first' date codes (without timezones) which will always be accepted. Could you try this file to see if it gets parsed appropriately?