#3736 [clock add] month miscalculation in Chicago time

[Andy Goth]

In the Chicago (Central) time zone, [clock add] can miscalculate month addition and subtraction:

[clock format [clock add [clock scan "May 01 00:00:00 1970" -timezone :UTC] 1 month] -timezone :UTC]
returns "Sun May 31 00:00:00 UTC 1970"

[clock format [clock add [clock scan "May 31 00:00:00 1970" -timezone :UTC] -1 month] -timezone :UTC]
returns "Fri May 01 00:00:00 UTC 1970"

Changing the time zone to UTC or CEST fixes the problem:

[clock format [clock add [clock scan "May 01 00:00:00 1970" -timezone :UTC] 1 month] -timezone :UTC]
returns "Mon Jun 01 00:00:00 UTC 1970"

Probably other time zones work as well. It's also possible other time zones are broken. It could be that the Chicago time zone is only broken when in Daylight Saving time.

This occurs in both Slackware Linux and MS-Windows XP.

[Andy Goth]

Logged In: YES
user_id=8653
Originator: YES

This problem exists in today's HEAD.

[Andy Goth]

Logged In: YES
user_id=8653
Originator: YES

The problem appears to be in [clock add]. [clock scan] and [clock format] generate the right results, of course assuming GNU date is right. :^)

[clock add 12960000 -1 month] returns 10368000, which is May 1. It should return 10281600, or Apr 30. The two values differ by 86400, one day.

Hmm, come to think of it... [clock add] takes a -timezone argument as well. Passing in -timezone :UTC to [clock add] makes it return 10281600, the expected result. I'm unsure why the -timezone argument matters in this case, though. This may still bear investigation.

[Kevin B KENNY]

Logged In: YES
user_id=99768
Originator: NO

I can't find a bug here.

[clock add] operates in the given timezone - in your case :America/Chicago.

In Chicago time, 12960000 is Sat May 30 19:00:00 CDT 1970
Subtracting 1 month yields

% clock add 12960000 -1 month -timezone :America/Chicago
10368000
% clock format 10368000 -timezone :America/Chicago
Thu Apr 30 19:00:00 CDT 1970

which is 1 month before the given date in Chicago time.

By contrast, in UTC, we have:

% clock format 12960000 -gmt 1
Sun May 31 00:00:00 GMT 1970

Subtracting 1 month yields the invalid date April 31, which gets trimmed to April 30:

% clock add 12960000 -1 month -gmt 1
10281600
% clock format 10281600 -gmt 1
Thu Apr 30 00:00:00 GMT 1970

All of which is exactly as I expect.

[SourceForge Robot]

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).