Talk:Day of the week

Same prog on different machine

Yes, and I see it is a 64bit machine, isn't it? I am still on plain 32 bit! --ShinTakezou 14:55, 12 December 2008 (UTC)

True. But it is all worth knowing :-) --Paddy3118 14:56, 12 December 2008 (UTC)

Hey - why not make it interesting and have the program print the years when Dec. 25 falls on Sunday through 2121. Let's see if any get this wrong. --64.238.49.65 15:11, 12 December 2008 (UTC)

The date is internally stored as seconds from the year 1970 (more or less). I've computed (2038-1970)*365*24*3600, obtaining 2144448000; now, we are near the limit for a 32bit signed integer... but not to the limit of a 64bit signed integer. I take a note for the day I will ask myself is it is worth buying a 64bit hardware :) About the 2121, 64bit systems still can :) With a 64bit signed int, you can really go a lot further (I wonder if you thought about a limit in the way the day is found) --ShinTakezou 15:22, 12 December 2008 (UTC)

Ada program

I've installed GNAT too, and tried the Ada code; it says:

yuletide.adb:1:06: "Ada.Calendar.Formatting" is not a predefined library unit

Should the Ada coders add a libheader or such an info? Or is it a GNAT problem? Would like to know. --ShinTakezou 15:28, 12 December 2008 (UTC)

When failing and when not on 32bit machine

I've written (and tested) the C and UNIX Shell code, showing that they stop in the year 2033, depending on the fact that both uses the (g)libc on a 32bit system; in fact a run on a 64bit machine was successful. But this must not make one think the same apply on e.g. Python and Java code: in fact I've test them too, and they give the right results even on my machine! So, they don't use the underlying libc to compute dates and time. Luckly! So they proved to be really system independent! --ShinTakezou 16:07, 12 December 2008 (UTC)