dezlov/pascaltz

Time zone database for Free Pascal / Lazarus

pascaltz's Issues

Parse error on a fixed negative DST offset in Zone definition

The parser fails on tzdata 2018g with an error:

Rule on Zone line " 1:00 -1:00 GMT 1947 Feb 23 2:00" not found.

Extend PascalTZ for time operations

Do you think that it will be interesting to extend library to perform precise time operations (to the second precision) so it can calculate seconds between two arbitrary times/dates ?

It could be important when calculating time (seconds) between to given moments when one is a few seconds before time change and second moment is just after time change as regular operation will result in wrong real time elapsed.

I have this problem in a project, fortunatly it is not a serious problem, but I have event time and duration and I must write the event finish time, evertyhing in local time. I'm just operating at GMT time instead the local time but some helper functions like "IncSecondsLocalTime" could be a good help for some people and specially the SecondsBetweenLocalTime(DateTime1,DateTime2).

fpc date operations most time work in an approximation style, so months/days elapsed between two dates sometimes do not return the exact value due its floating point nature, so things like months between 2017.01.31 and 2017.02.28 (if I recall correctly) returns 0.98 which is not 1.00 month.

Fix ReloadDatebasePath on Unix OS

Please check request #5

On Unix, passing a directory name will result in True with FileExists function (because directory is file too in Unix). So it's valid to check if is really file not directory.
Perhaps it's more beautiful to just put a check on the directory at the beginning, but I'm not sure if this matches the logic of the code. That is it is possible and so, it is possible

if DirectoryExists(FDatabasePath) then
  ParseDatabaseFromDirectory(FDatabasePath)
else if FileExists(FDatabasePath) then
  ParseDatabaseFromFile(FDatabasePath)

P.S. Thanks for awesome and useful lib!

Parse error "25:00" Hours component "25" is out of range.

I am getting this error with the latest 2018g timezone database file:

Parse error at line 3422: "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" [Failed to parse time string "25:00" with error: Hours component "25" is out of range.].

Zone info not found for link FROM "America/Los_Angeles" TO "US/Pacific-New"

I am getting this now when pacificnew is used:

Parse error at line 29: "Link America/Los_Angeles US/Pacific-New ##" [Zone info not found for link FROM "America/Los_Angeles" TO "US/Pacific-New".].

PS. Thank you for fixing the other errors so quickly!

TimeToSeconds Range check error

In uPascalTZ_Tools, function TimeToSeconds:

case TwoColons of
[...]
Hours:=StrToInt(TimeIterator.GetNextWord);
[...]

Hours is 0..23 but some rules like 'Rule Egypt 1995 2005 - Sep lastThu 24:00 0 -' writes the time as 24:00 which will raise a range check error.

By now I surround it with {$PUSH}{$RANGECHECKS OFF}Hours:=StrToInt(TimeIterator.GetNextWord);{$POP} but I'm worried about possible erroneous calcs.

Note: Thank you for fixing my tons of issues :-)

TZ_TIMEZONELETTERS_SIZE = 11 in tzdata2017b

TZ_TIMEZONELETTERS_SIZE should be raised to 11 to accomodate tzdata2017b for at least:

'Asia/Tehran' -> ' 3:30 Iran +0330/+0430'

Cannot resolve macro that falls into another month

A macro for finding a week day has been adjusted for zone Asia/Hong_Kong in tzdata2019b such that the target day falls into another month, which is currently cannot be handled by PascalTZ library.

See the extracts for "Sun>=28" and "Sun>=31":

Rule	HK	1948	1952	-	Oct	Sun>=28	3:30s	0	-
Rule	HK	1953	1964	-	Oct	Sun>=31	3:30	0	-

Error raised in MacroFirstWeekDay function:

No valid first week day for "Sunday" after 1952.10.28

Precompiled tz base.

In PascalTZ 1.00 the fields storing strings are arrays of chars for 2 reasons, one is speed allocating space and the most important one because I was thinking in store everyting once parsed in a binary file, so all structures can be read from disk in a "flash" instead parsing every rule.

Your code is pretty good in speed, but reading from a binary file should be much faster.