Year 2038 problem with calendar (Bad holiday list items)

Year 2038 problem with calendar (Bad holiday list items)

[Sascha Wilde]

When using calendar to show holidays for years past 2037 I get some
errors.  To reproduce: 

emacs -Q
M-x calendar RET
x
o 2038 RET February RET

I get the following errors:
Bad holiday list item: (if (fboundp (quote atan)) (holiday-chinese-new-year))
Bad holiday list item: (if (progn (require (quote cal-dst)) t) (funcall (quote holiday-sexp) calendar-daylight-savings-starts (quote (format Daylight Saving Time Begins %s (if (fboundp (quote atan)) (solar-time-string (/ calendar-daylight-savings-starts-time (float 60)) calendar-standard-time-zone-name) )))))
Bad holiday list item: (funcall (quote holiday-sexp) calendar-daylight-savings-ends (quote (format Daylight Saving Time Ends %s (if (fboundp (quote atan)) (solar-time-string (/ calendar-daylight-savings-ends-time (float 60)) calendar-daylight-time-zone-name) ))))

I'd consider this a minor issue, as only a few holiday items seem
effected, but it's somewhat annoying anyway...

cheers
sascha
-- 
Sascha Wilde
Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder
gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt.

Re: Year 2038 problem with calendar (Bad holiday list items)

[Ed Reingold]

> When using calendar to show holidays for years past 2037 I get some
> errors.  To reproduce: 
> 
> emacs -Q
> M-x calendar RET
> x
> o 2038 RET February RET

This works perfectly for me.  Displaying all the holidays gave me:

Friday, January 1, 2038: New Year's Day
Saturday, January 16, 2038: Shabbat Shirah
Monday, January 18, 2038: Martin Luther King Day
Thursday, January 21, 2038: Tu B'Shevat
Tuesday, February 2, 2038: Groundhog Day
Thursday, February 4, 2038: Chinese New Year (Wu-Wu)
Saturday, February 6, 2038: Islamic New Year 1460
Sunday, February 14, 2038: Valentine's Day
Monday, February 15, 2038: President's Day
Saturday, March 6, 2038: Shabbat Shekalim
Wednesday, March 10, 2038: Ash Wednesday
Sunday, March 14, 2038: Daylight Savings Time Begins 2:00am (CST)
Wednesday, March 17, 2038: St. Patrick's Day
Thursday, March 18, 2038: Fast of Esther
Saturday, March 20, 2038: Vernal Equinox 7:39am (CDT)
Saturday, March 20, 2038: Erev Purim
Saturday, March 20, 2038: Shabbat Zachor
Sunday, March 21, 2038: Purim
Monday, March 22, 2038: Shushan Purim
Saturday, March 27, 2038: Shabbat Parah

Re: Year 2038 problem with calendar (Bad holiday list items)

[Nick Roberts]

 > When using calendar to show holidays for years past 2037 I get some
 > errors.  To reproduce: 
 > 
 > emacs -Q
 > M-x calendar RET
 > x
 > o 2038 RET February RET

Another problem for after the release?  I guess it depends on which comes
sooner.

Actually I think it's probably a glibc problem.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Year 2038 problem with calendar (Bad holiday list items)

[Andreas Schwab]

Sascha Wilde <wilde@sha-bang.de> writes:

> When using calendar to show holidays for years past 2037 I get some
> errors.

You cannot represent a date beyond 2038-01-19T03:14:07+00:00 in a 32 bit
signed time_t.  Emacs depends on the libc time functions to do time zone
calculations.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Year 2038 problem with calendar (Bad holiday list items)

[Ed Reingold]

> You cannot represent a date beyond 2038-01-19T03:14:07+00:00 in a 32 bit
> signed time_t.  Emacs depends on the libc time functions to do time zone
> calculations.

Not the way I originally wrote it!

Re: Year 2038 problem with calendar (Bad holiday list items)

[Sascha Wilde]

Ed Reingold <reingold@emr.cs.iit.edu> wrote:

>> When using calendar to show holidays for years past 2037 I get some
>> errors.  To reproduce: 
>> 
>> emacs -Q
>> M-x calendar RET
>> x
>> o 2038 RET February RET
>
> This works perfectly for me.  Displaying all the holidays gave me:

Strange.  I get the errors I reported in my last mail, and pressing `a'
only provides me with the following:

Friday, January 1, 2038: New Year's Day
Monday, January 18, 2038: Martin Luther King Day
Tuesday, February 2, 2038: Groundhog Day
Saturday, February 6, 2038: Islamic New Year 1460
Sunday, February 14, 2038: Valentine's Day
Monday, February 15, 2038: President's Day
Wednesday, March 10, 2038: Ash Wednesday
Wednesday, March 17, 2038: St. Patrick's Day
Saturday, March 20, 2038: Vernal Equinox 2:39pm (CEST)
Sunday, March 21, 2038: Baha'i New Year (Naw-Ruz) 195

sascha
-- 
Sascha Wilde
Hauptfunktion einer GUI ist es IMHO, die dadurch verlorene Zeit durch
einen höheren Spaß-Faktor zu kompensieren. Essentiell ein
Computerspiel.  --  Rainer Weikusat in d.c.o.u.d

Re: Year 2038 problem with calendar (Bad holiday list items)

[Glenn Morris]

Sascha Wilde wrote:

> Bad holiday list item: (if (fboundp (quote atan))
> (holiday-chinese-new-year)) Bad holiday list item: (if (progn
> (require (quote cal-dst)) t) (funcall (quote holiday-sexp)
> calendar-daylight-savings-starts (quote (format Daylight Saving Time
> Begins %s (if (fboundp (quote atan)) (solar-time-string (/
> calendar-daylight-savings-starts-time (float 60))
> calendar-standard-time-zone-name) ))))) Bad holiday list item:
> (funcall (quote holiday-sexp) calendar-daylight-savings-ends (quote
> (format Daylight Saving Time Ends %s (if (fboundp (quote atan))
> (solar-time-string (/ calendar-daylight-savings-ends-time (float
> 60)) calendar-daylight-time-zone-name) ))))

Works for me. What happens if you do:

(setq calendar-dst-check-each-year-flag nil)

What does your system clock say about DST transitions in 2038?

What are the details of your Emacs version, OS, etc?

Re: Year 2038 problem with calendar (Bad holiday list items)

[Glenn Morris]

Glenn Morris wrote:

> Works for me. 

OK, now I can reproduce it on a 32-bit system. As has been said, it's
because things like:

(encode-time 1 0 0 1 1 2039)

fail on such systems ("specified time is not representable").

> (setq calendar-dst-check-each-year-flag nil)

This does avoid the problem for me.


I will see if this can be handled more gracefully, but I see no need
for this to be changed before the release of Emacs 22. Assuming, as
Nick says, that this happens in the next 30 years...

Re: Year 2038 problem with calendar (Bad holiday list items)

[Glenn Morris]

Ed Reingold wrote (on Mon, 16 Apr 2007 at 15:12 -0500):

> As I wrote to the whole group, I never wrote code that would break
> like this; what changed?

cal-dst (optionally, but by default) no longer assumes that the DST
transition occurs at the same date in every year. This was prompted by
the recent US DST changes.

I think you'll find that the original code would break in 2038 on
existing 32-bit systems, because even (current-time) will (?) fail
there.

Anyway, I have a trivial workaround for this issue.

Re: Year 2038 problem with calendar (Bad holiday list items)

[Glenn Morris]

Ed Reingold wrote (on Mon, 16 Apr 2007 at 17:44 -0500):

> From the point of view of the calendar (as explained in the docs)
> ONLY THE CURRENT RULES ARE RELEVANT, even if that is historically
> wrong (there was no Thanksgiving before in the US before about 1850,
> say). Getting that correct historically is well-nigh impossible.

Historical correctness was not the intent. The intent was to fix a
bug.

http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00060.html

Note how it is possible for me to convey this information to you
without shouting.

Re: Year 2038 problem with calendar (Bad holiday list items)

[Glenn Morris]

Glenn Morris wrote:

> Anyway, I have a trivial workaround for this issue.

Now installed, just missed 22.0.98. Blast.

Re: Year 2038 problem with calendar (Bad holiday list items)

[Sascha Wilde]

Glenn Morris <rgm@gnu.org> wrote:
> OK, now I can reproduce it on a 32-bit system. As has been said, it's
> because things like:
>
> (encode-time 1 0 0 1 1 2039)
>
> fail on such systems ("specified time is not representable").

So it's the classical y2038 problem.  :-)
(Which seems to be implicitly solved on 64bit systems, which is a good
thing to know...)

>> (setq calendar-dst-check-each-year-flag nil)
>
> This does avoid the problem for me.

Yes, works for me to.  However, the list is still much shorter than
that posted by Ed, I wonder why...

> I will see if this can be handled more gracefully, but I see no need
> for this to be changed before the release of Emacs 22. Assuming, as
> Nick says, that this happens in the next 30 years...

I agree, this is a minor issue.

cheers
sascha
-- 
Sascha Wilde
"Structure is _nothing_ if it is all you got.  Skeletons _spook_ people if
 thwy try to walk around on their own.  I really wonder why XML does
 not."            -- Erik Naggum <erik@naggum.net> in comp.lang.lisp