Hello again :) Can someone please explain this: Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 -0:25:21 1:00 IST 1916 Oct 1 2:00s The last line has -0:25:21 min as the GMT offset - is it possible that the rule name is "1:00" ? Lines 428-430 in the europe file. Thank you much, Srdjan
From: "srdjan krajnalic" Can someone please explain this: Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 -0:25:21 1:00 IST 1916 Oct 1 2:00s The last line has -0:25:21 min as the GMT offset - is it possible that the rule name is "1:00" ? Lines 428-430 in the europe file.
The same type of problem you mentioned earlier. The TZ database is not of pure database quality. In most cases fields are separated by tabs, but sometimes a space or a space run is the field separator. It is not possible to import the TZ database into a simple database program or a spreadsheet. Each and every field should be manually checked and separated if necessary. Or you will have to write an intelligent importer, parser or converter yourself.
Hi Oscar, I got that far and have all the files corrected using tab now (I'll check them again when this issue is resolved). That was the easy part :-) In this case the problem is that the RULE NAME is "1:00" which is not typical. Typically, names are something like GB-Eire or C-Eur. So my problem is that I'm not sure what to do with what appears to be extra or invalid data. -----Original Message----- From: Oscar van Vlijmen [mailto:ovv@hetnet.nl] Sent: Sunday, July 02, 2006 3:00 PM To: tz@lecserver.nci.nih.gov Subject: Re: Possible corrections?
From: "srdjan krajnalic" Can someone please explain this: Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 -0:25:21 1:00 IST 1916 Oct 1 2:00s The last line has -0:25:21 min as the GMT offset - is it possible that the rule name is "1:00" ? Lines 428-430 in the europe file.
The same type of problem you mentioned earlier. The TZ database is not of pure database quality. In most cases fields are separated by tabs, but sometimes a space or a space run is the field separator. It is not possible to import the TZ database into a simple database program or a spreadsheet. Each and every field should be manually checked and separated if necessary. Or you will have to write an intelligent importer, parser or converter yourself.
From: "srdjan krajnalic" In this case the problem is that the RULE NAME is "1:00" which is not typical. Typically, names are something like GB-Eire or C-Eur. So my problem is that I'm not sure what to do with what appears to be extra or invalid data.
The problem is not unique. There are many such instances in all data files, where a rule name appears to be a time offset. My theory: probably a relic from a conversion process trying to convert space (runs) into tabs. In several cases a tab didn't get in so a space remained and in other cases an empty field was deleted.
From: "srdjan krajnalic" In this case the problem is that the RULE NAME is "1:00" which is not typical. Typically, names are something like GB-Eire or C-Eur. So my problem is that I'm not sure what to do with what appears to be extra or invalid data.
From: Oscar van Vlijmen The problem is not unique. There are many such instances in all data files, where a rule name appears to be a time offset.
I should have added: this is explained in the zic manual: <quote> RULES/SAVE The name of the rule(s) that apply in the time zone or, alternately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. </quote> For independent developers it would have been more convenient if the TZ database were constructed according to more common database markup rules like: 1) ONE type of field separator, for instance one tab, not any white space. 2) No empty first fields on continuation lines. 3) ONE datatype / meaning per field. Suggested action: none. The TZ applications work as advertized and the usability of the TZ database outside the primary application is not guaranteed. Sorry for my annoying remarks, but the independent TZ database users keep coming and they apparently get easily confused by the current structure or markup of the data files.
Oscar van Vlijmen <ovv@hetnet.nl> writes:
Sorry for my annoying remarks, but the independent TZ database users keep coming and they apparently get easily confused by the current structure or markup of the data files.
In this particular case, the user had not read the manual, and didn't even know one existed. That would be a problem no matter what format we had chosen. Perhaps we could forestall future questions like this by starting each data file with a line saying "The format of this file is described in <http://www.twinsun.com/man/zic.8.html>." or something like that.
srdjan krajnalic wrote:
Can someone please explain this:
Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 -0:25:21 1:00 IST 1916 Oct 1 2:00s
The last line has -0:25:21 min as the GMT offset - is it possible that the rule name is "1:00" ?
1:00 means a one hour offset added to local standard time. This is documented in the zic man page (http://linuxcommand.org/man_pages/zic8.html): RULES/SAVE The name of the rule(s) that apply in the time zone or, alternately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. -- Philip Ross http://tzinfo.rubyforge.org/ -- DST-aware timezone library for Ruby
participants (4)
-
Oscar van Vlijmen -
Paul Eggert -
Philip Ross -
srdjan krajnalic