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)

What I'm referring to is that 2100 is not a leap year. There may be software out there that miscalculates this, and therefore gets the dates wrong. --Rldrenth 16:17, 12 December 2008 (UTC)

I hope it goes ok, since how to compute correctly leap years is on the first page of every good programming book —well at least it was on the books I've seen :D --ShinTakezou 16:29, 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)

Did you used the -gnat05 switch? Ada.Calendar.Formatting is a library unit of Ada 2005. However, I presume you have some very outdated version of GNAT, because even without the switch, the compiler should tell:

yuletide.adb:1:18: warning: "Ada.Calendar.Formatting" is an Ada 2005 unit

My version is 20081029-43. OK, it is GNAT Pro. GNAT GPL should be xxxxxxxx-41, I guess. --Dmitry-kazakov 16:46, 12 December 2008 (UTC)

Tried... I've GNAT 4.2.3, GPL of course... maybe it's a Pro only unit :( --ShinTakezou 18:05, 12 December 2008 (UTC)

No, it is a part of the standard library. I have tested it at home on my Linux box with GNAT GPL:

>gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /cardhu.b/gnatmail/release-gpl/build-cardhu/src/configure --prefix=/usr/gnat --target=i686-pc-linux-gnu --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --enable-languages=c,ada --disable-nls --disable-libada --enable-checking=release --enable-threads=posix
Thread model: posix
gcc version 4.1.3 20080522 for GNAT GPL 2008 (20080521)

Then compiled as:

>gnatmake -gnat05 yuletide.adb

I've got:

>./yuletide.adb
2011-12-25 00:00:00
2016-12-25 00:00:00
2022-12-25 00:00:00
2033-12-25 00:00:00
2039-12-25 00:00:00
2044-12-25 00:00:00
2050-12-25 00:00:00
2061-12-25 00:00:00
2067-12-25 00:00:00
2072-12-25 00:00:00
2078-12-25 00:00:00
2089-12-25 00:00:00
2095-12-25 00:00:00
2101-12-25 00:00:00
2107-12-25 00:00:00
2112-12-25 00:00:00
2118-12-25 00:00:00

I think you have some installation problem. Check the system path. It seems that the compiler cannot find the include directory, where the library files are stored. --Dmitry-kazakov 19:08, 12 December 2008 (UTC)

Thanks for your time, I will check all the env. --ShinTakezou 19:26, 12 December 2008 (UTC)

Ada hard time...

I did all the kind of tests I could do. At the end, taken a look at the *.ads file (ugly naming conventions!), and at the end I successfulling compiled the following code:

<ada>with GNAT.Calendar; use GNAT.Calendar; with GNAT.Calendar.Time_IO; use GNAT.Calendar.Time_IO; with Ada.Text_IO; use Ada.Text_IO;

procedure Yuletide is begin

  for Year in 2008..2121 loop
     if Day_Of_Week (Time_Of (Year, 12, 25, 0, 0, 0)) = Sunday then
        Put_Line (Image (Time_Of (Year, 12, 25, 0,0,0), ISO_Date));
     end if;
  end loop;

end Yuletide;</ada>

Which by the way on my machine outputs (only last lines)

2089-12-25
2095-12-25

raised CONSTRAINT_ERROR : yuletide.adb:8 range check failed

Anyway, at least I discovered how to arrange the code on my system with my poor GNAT :) --ShinTakezou 20:52, 12 December 2008 (UTC)

I see, now it seems to be clear. First of all, GNAT.Calendar is not a part of the standard. But that is not the problem, Ada.Calendar is. The standard (Ada 2005) requires Year_Number to be at least in the range 1901..2399. See LRM 9.6 11/2. So the code given in the Ada solution must work, or else your compiler is not Ada 2005. From your attempts I deduce that it is indeed not. You have an Ada 95 compiler. In Ada 95 the range of Number was narrower, 1901 .. 2099. This is why your code produces an exception. You can slightly modify your code:

<ada> with GNAT.Calendar; use GNAT.Calendar; with GNAT.Calendar.Time_IO; use GNAT.Calendar.Time_IO; with Ada.Text_IO; use Ada.Text_IO; with Ada.Calendar; use Ada.Calendar;

procedure Yuletide is begin for Year in Year_Number range 2008..2121 loop -- Explicitly specify it as Year_Number if Day_Of_Week (Time_Of (Year, 12, 25, 0, 0, 0)) = Sunday then Put_Line (Image (Time_Of (Year, 12, 25, 0,0,0), ISO_Date)); end if; end loop; end Yuletide;</ada>

Now the compiler will warn you that Year is not in the range of Year_Number and you will get Constraint_Error at run time. So the problem is that your GNAT is not Ada 2005. Remove it and install a new one. The official distributor is here. Register yourself (it is free) and download GNAT GPL for your platform. --Dmitry-kazakov 21:48, 12 December 2008 (UTC)

Thanks again. I imagined that GNAT.* is not standard, but with Ada.Calendar nothing worked :( Going to update out of the repositories :D --ShinTakezou 23:27, 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)

Note: UNIX Shell example uses standard tools like date, which in turn uses (g)libc library, that in its standard POSIX implementation is limited by the underlying hardware max integer. So on 64bit machines it will give the right answers until 2121; on 32bit machines, no, no matter how the code is changed (it should use some other program and avoid date... of course we could use any of the interpreter installed on a system, but it would be almost cheating:D) --ShinTakezou 18:10, 12 December 2008 (UTC)

Yuletide Wish

I thought I would write up the task at lunchtime when at work, and have time enugh to do a Python implementation when I got home. No such luck, you beat me too it :-)

Well, let me be the first to wish you fellow RC'ers happy holidays then. --Paddy3118 17:12, 12 December 2008 (UTC)

Thanks and the same to you all. --ShinTakezou 18:06, 12 December 2008 (UTC)

UNIX Shell

As modified by 71.106.183.17. I suggest to give back my implementation, it should be a little bit better, since this one now relies on the execution of another program (seq) while the for((..)) version is all executed into the bash interpreter. Maybe this last version works also with other shells, but I've put the Works With with a reason then! Let's think about. --ShinTakezou 00:28, 14 December 2008 (UTC)

I am happy to use your original, although I did check and seq is available on Cygwin. --Paddy3118 06:44, 14 December 2008 (UTC)