Re: gcal reporting Christmas day as the 26th?

[Roger]

That corresponds with what I'm seeing here, as US_OH is also stated as  
SASA_SUMO too, and should be SASA_SUSU.

I do believe, if I'm believing in the right thing for a change, all US States's 
holidays should follow the same "observe_us_hdy = SASA_SUSU;" statement.

Likely explains why, when I did:

$ strace -a 120 gcal --holiday-list=long  --cc-holidays=US_NY --type=standard . 
 > /tmp/test-ny.log 2>&1
$ strace -a 120 gcal --holiday-list=long  --cc-holidays=US_NY --type=standard . 
 > /tmp/test-oh.log 2>&1

And diff'ed the log files, the changed output tended to point towards coding.  
But again, guess work.

Shrugs... darn it's not a related ubuntu/systemd related bug...

Roger


> On Sat, Dec 24, 2022 at 03:26:16PM -0700, Stephen Wood wrote:
>   Thanks, everyone for the info. I think I've figured it out.
>   It looks like some states incorrectly have observed_us_hdy set
>   incorrectly in� hd-data5.c:
>
>   observe_us_hdy = SAFR_SUMO;
>
>   While it should be:
>
>   observe_us_hdy = SASA_SUSU;
>
>   The logic for this is handled in hd-data1.c and it moves holidays
>   forward or backward so they don't land on weekends (according to the
>   comments in hd-defs.h). A quick update and Christmas is back:
>   $ ./src/gcal --holiday-list=long --cc-holiday=US_ID --debug=all | grep
>   Christmas
>   Christmas Day (US_ID) �  �  �  �  �  �  �  �  �  � + Sun,
>   � Dec:25th:2022 = �  +1 day
>   Many states are correctly set to the right observed_us_hdy setting,
>   which I think explains why this bug has gone so long unnoticed. Not
>   sure how many gcal contributors live in Idaho, but there's at least 1
>   now!
>   I'd like to get a patch out and save Christmas for everyone living in
>   the SAFR_SUMO states, but I'm not sure where to submit the patch. Any
>   ideas?
>   --- a/src/hd-data5.c
>   +++ b/src/hd-data5.c
>   @@ -1393,7 +1393,7 @@ us_id_hdy (init_data, detected, easter, year,
>   hd_elems, fday, count)
>   � */
>   � {
>   �  � ptr_cc_id = "US_ID";
>   - � observe_us_hdy = SAFR_SUMO;
>   + � observe_us_hdy = SASA_SUSU;
>   �  � us_hdy (init_data, detected, easter, year, hd_elems, fday, count);
>   � }
>   Thanks again.
>   Stephen
>
>   On Sat, Dec 24, 2022 at 2:18 PM Roger <rogerx.oss@gmail.com> wrote:
>
>     I've also just tried a few of the other US states, and New York
>     (--cc-holidays=US_NY) does report the correct 25th and 1st for
>     Christmas and
>     New Years, while apparently all other US states report 26th and 2nd.
>     $ ls -al /etc/localtime
>     /etc/localtime -> /usr/share/zoneinfo/America/New_York
>     I changed /etc/localtime to a few other /usr/share/zoneinfo/ files,
>     such as:
>     /usr/share/zoneinfo/America/Phoenix
>     /usr/share/zoneinfo/US/Eastern
>     ... and no change in reporting the 26th/2nd.
>     Again, this seemingly only popped-up once installing Ubuntu and upon
>     experiencing Ubuntu BIOS/RTC clock timezone problems.�  shrugs...
>     Dates on gcal source files indicate no changes since 2017, unless a
>     New Yorker
>     hacked the code.
>     WORKAROUND: If in US, set to US_NY for reporting correct US
>     holidays.
>     Roger
>     > On Fri, Dec 23, 2022 at 04:00:36PM -0700, Stephen Wood wrote:
>     >�  � Hello, gcal maintainers!
>     >�  � It seems gcal is reporting the wrong day for Christmas, the
>     26th
>     >�  � instead of the 25th. At first I thought maybe I was localizing
>     >�  � incorrectly, but I've tried with various US_<STATE> and all of
>     them are
>     >�  � reporting Christmas as the 26th.
>     >�  � $ date
>     >�  � Fri 23 Dec 2022 03:17:50 PM MST
>     >�  � $ gcal --holiday-list --cc-holiday=US_ID | grep Christmas
>     >�  � Christmas Day (US_ID) ��  ��  ��  ��  ��  ��  ��  ��  ��  � +
>     Mon,
>     >�  � � Dec:26th:2022 = ��  +3 days
>     >�  � $ gcal --version
>     >�  � gcal (GNU cal) 4.1
>     >�  � Is there something I'm doing wrong? I also notice Christmas
>     Eve is
>     >�  � missing which makes me suspicious that I have the wrong flags
>     set
>     >�  � someplace.
>     >�  � Thank you,
>     >�  � Stephen

signature.asc
Description: PGP signature