CET, CEST problem

[cs42]

Hi,

I just found a weird but consistent behaviour in DiaDEM 9.10.2260.

I have data recorded to a Citadel database in winter (CET: GMT+1) and want to load part of it now (CEST: GMT+2). So I define a time frame of lets say: 01.02.2006 10:00 to 01.02.2006 11:00 in the DB import settings (I do an averageing over 5 seconds as well). But the time frame of 01.02.2006 09:00 to 01.02.2006 10:00 will be imported...

This is a bit annoying, because I always forget first to add an hour (fortunately I'm loading short junks currently)...

Cheers,
Carsten

[Brad_Turpin]

Hi Carsten,

I have officially passed your feedback on to R&D for consideration.  Their immediate response was that they are using a Microsoft date/time control in the configuration dialog, and that control (like the rest of MS products) deals with summer time by pretending it doesn't exist.  For the time being, that's how DIAdem's interface to Citadel is going to deal with it also.

Perhaps we'll get something cleverer in the future,
Brad Turpin
DIAdem Product Support Engineer
National Instruments

[cs42]

Hi Brad,

thanks for your reply.

Actually I'd just use GMT/UTC internally and never local time (neither on storing nor on recalling data). This way you just have to convert the local data of a widget to GMT and vice versa. I suppose even MS controls/libraries should have a function for this...

Cheers,
    Carsten

[jdr_ni]

Hi,

All of the internal timestamps used by DIAdem/Citadel are in UTC format. This problem occurs when we must rely on Microsoft's functions to convert between UTC and local time. Microsoft always uses the current offset from GMT to do its conversions, so timestamps created 6 months ago at GMT+1 are converted using the current  offset of GMT+2. Microsoft's simplification is somewhat justifiable, as the algorithm by which the UTC offset changes varies by region (including individual states in the United States) and by year (it changed this year in the United States), thus making it very difficult to create a generic function for calculating the UTC offset. The problem, of course, is that timestamps stored in UTC will be rendered differently depending on the time of year when they are viewed. Also, some internal NI functions do correct for UTC offset changes, which can cause the same timestamp to be rendered differently in different applications, creating further confusion.

Anyway, thank you for the report. This is certainly something that we are looking into.