We appreciate the contributions many of you have been able to make towards repairing the storm damage and keeping a roof over our heads. With your help we’ve been able to complete much of the critical work. There is still work to be done to secure the house and your continued support will be a huge help.
Guests have read-only access to our forums. If you wish to participate you will need to register. Be sure to activate your account from the email sent to you when you register.
Hi Glenn, I need some info around the timezone function that is giving issues for my users in China.
Reading the INI file, it returns <n/a> instead of the time for that region.
When we run below, it returns Chinese characters, but not sure if that is the issue.
REG2=key:HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones\China Standard Time, values-to-rows:1, display:%2 It displays “中国夏令时” which is the DLT value
Using Process Monitor tool, it looks like DTI looks for 'Dynamic DST' value that does not exist (see screenshot). That value does not exist in my registry either, but it is still displaying fine for me and many others. Any clue?
Hi Glenn, I need some info around the timezone function that is giving issues for my users in China.
Reading the INI file, it returns <n/a> instead of the time for that region.
When we run below, it returns Chinese characters, but not sure if that is the issue.
REG2=key:HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones\China Standard Time, values-to-rows:1, display:%2 It displays “中国夏令时” which is the DLT valueUsing Process Monitor tool, it looks like DTI looks for 'Dynamic DST' value that does not exist (see screenshot). That value does not exist in my registry either, but it is still displaying fine for me and many others. Any clue?
I tested the following item:
DATETIME=interval:5,text:China,display:%long_date% %10,timezone:China Standard Time
and it gave me the correct result. The trick I think is to put the exact text from that "Std" entry into the timezone option. So I presume if the locale is China those entries will be in Chinese (Mandarin?).
DATETIME=interval:5,text:China,display:%long_date% %10,timezone:中国标准时间
The code that loads the registry time zone information looks like this. It reads TZI, Std & Dlt
Reg.ReadBinaryData('TZI', TZI, SizeOf(TTZI));
TziArray[i].Bias := TZI.Bias;
s := Reg.ReadString('Std');
StringToChar(s, TziArray[i].StandardName);
TziArray[i].StandardDate := TZI.StandardDate;
TziArray[i].StandardBias := TZI.StandardBias;
s := Reg.ReadString('Dlt');
StringToChar(s, TziArray[i].DaylightName);
TziArray[i].DaylightDate := TZI.DaylightDate;
TziArray[i].DaylightBias := TZI.DaylightBias;
Let me know if the above info solves the problem. I think the manual might be inaccurate.
ps. I edited this a bunch of times the deeper I got into the code 🙂
Hi Glenn,
Thank you so much for looking into this.
DATETIME=interval:5,text:China,display:%long_date% %10,timezone:中国标准时间
did fix the issue for the China users experience this issue. So it looks like the local language setting is the determining factor. But I cannot update this for all my users, not even in China as some have set this to English (US) and I assume something similar could happen for Japan users. Any suggestions how to make this language-agnostic without building complex nested IF statements?
@tacod Just need clarification so I understand the requirements.
You develop a DTI ini file that is distributed to people around the world.
The same ini file for everyone.
It contains the time in specific time zones so that everyone can see the time in said zones.
The problem is identifying the required time zones is machine dependent. Eg all the time zones in my registry are declared in English. This is not necessarily so in other regions.
So we need a way of finding a time zone on any machine that is not dependent on local language settings.
After looking at it some more, it seems I probably should be looking at the key rather than the values. The key is regarded as an ID and appears to be the same regardless of the local language. perhaps you could confirm that.
