views:

722

answers:

2

We are trying to interpret the data stored in Axapata's TIMEZONESRULESDATA table. Particularly, we'd like to figure out how it stores DST begin/end times. So far, my guess is:

TZENUM: foreign key referencing TIMEZONESLIST (time zone name and identifier)
YEAR: 0 if rule is valid indefinitely or a year where the timezone rule is in effect
BIAS: offset to UTC time in minutes
DBIAS: offset of DST (added to BIAS to get total offset from UTC)

Now for the part I don't understand:

DYEAR,DMONTH,DDAYOFWEEK,DDAY,DHOUR,DMINUTE,DSECOND
SYEAR,SMONTH,SDAYOFWEEK,SDAY,SHOUR,SMINUTE,SSECOND

I would guess from the dates that the D* is the start date of DST and S* is end. However, I do not understand why it would need a year and a dayofweek field. Also, *DAY does not seem to indicate the day of month - at least it doesn't indicate the correct one for switching DST. It also doesn't seem to correspond to the dates at which Axapta's own DateTimeUtil or Form autoconversion converts the dates.

Does anyone know how to interprete this table? Or where I could look it up?

Sören

A: 

DDAY and SDAY represents week of month (1-4, 5 = last week)

DDAYOFWEEK and SDAYOFWEEK represents day of week (0 = Sunday)

How will you use this information?

Jan B. Kjeldsen
We were missing the 5 = last week part - thanks! Am I correct in assuming that if an entry is only valid for a specific year the SDAY will be the exact day of month? Also, what does it mean to have a non-0 entry for the year? Are the settings valid for that year only or from that year onwards?We intend to use the data to write our own local-timezone/DST to UTC conversion SQL (We cannot use X++ in this case). The idea is to use SQL Server's datetimeoffset datatype to store datetimes.
BuschnicK
I don't know about the the exact meaning of year. AX is prepared for import of timezone rules, so my guess would be specific year only. Testing will show.Good luck with your local time conversion, but my initial feeling is that you are on a wrong track.
Jan B. Kjeldsen
"wrong track" - my gut agrees with you. However, what do you propose? We can only use SQL and we must convert arbitrary dates (past,present,future) from an arbitrary timezone to UTC.
BuschnicK
See the following link: http://weblogs.asp.net/sbehera/archive/2006/01/20/435994.aspxWhy can you only use Transact-SQL?Maybe it is not the best tool.Try Python! (SQL Server integration is available.)
Jan B. Kjeldsen
+1  A: 

DDAY and SDAY looked like they indicate the week of month, but then we found DDAY- and SDAY-values of 6, 23 or 28. Are these the weeks of the year, or were the values > 5 hijacked for individual days?

My theory was this: with DMONTH = 8 and DDAYOFWEEK = 6, we have

  • DDAY = 4 ==> 4th saturday in August
  • DDAY = 5 ==> last saturday in August
  • DDAY = n > 5 ==> n-th of August (possible clash with DDAYOFWEEK?)

So what are SDAYs and DDAYs that are larger than 5?

Christian Severin