公元纪年的来历     公元是“公历纪元”的简称，是国际通行的纪年体系。以传说中耶稣基督的生年为公历元年（相当于中国西汉平帝元年）。 
    由于公元纪年的起点是公元1年，而没有“公元0年”，所以大多数对公元纪年有充分了解的科学家和世界上大多数权威天文机构，都明确支持21世纪始于2001年的说法。  
     公元1年1月1日是星期一。因此我们可以用某天的年月日推算出这一天是星期几（WEEKDAY）。
typedef unsigned long ULONG;
typedef unsigned int        UINT;
/*
参数输出：1~7 对应星期一至星期天
*/


typedef unsigned long ULONG;


typedef unsigned int        UINT;


int GetWeekDay(int nYear, int nMonth, int nDay)

{  

    ULONG lWeekDay = 0;    //要返回的weekday

    ULONG lYear = nYear;     

    ULONG lMonth = nMonth;  

    ULONG lDay = nDay;

    ULONG lDayCount = 0 ;   //从1月1日到上月底的累计天数


    UINT uArrMonth[]={31,28,31,30,31,30,31,31,30,31,30,31};


    for(unsigned int i=0;i<(lMonth-1);++i)   

          lDayCount += uArrMonth[i];    


    if ( nMonth > 2)

    {

        if ( ( (lYear%4 == 0) && (lYear%100 != 0 ) ) || (lYear%400 == 0) )  //计算闰年 

              ++lDayCount ;   

    }


    lWeekDay = ((lYear-1)*365 + (lYear-1)/4 - (lYear-1)/100 + (lYear-1)/400 + lDayCount + lDay )%7;


    if (lWeekDay==0)       //   

        lWeekDay = 7;           //星期几


    return (int)lWeekDay;

}
 
     其实不需用long数据类型来计算，完全可以采用int型。但用了long型可以保证到一百万年后，该函数仍然正确。
 

某日发现 DateTools 的 weekday 方法在不同 iOS 上计算出的结果不一样的问题。具体表现为：在 iOS 10 上计算出的结果比 iOS 12 上的结果少一天。比如同样是 2019-09-23，iOS 10 上计算结果为 1，而 iOS 12 上计算结果为 2。
跟踪代码发现，weekday 方法中调用了 [self componentForDate:self type:DTDateComponentWeekday calendar:nil]; 一句。
这里的 calendar 参数为 nil 表明将使用默认日历，而默认日历的 timezone 默认将使用本地时区。
但是，在 iOS 11 之前，NSTimeZone 无法正确获取系统设置的时区！因而导致计算出的结果少了一天。
分别在 iOS 11-12 和 iOS 10-10.3 下调用 NSTimeZone 的 defaultTimeZone、localTimeZone 和 systemTimeZone，以及 [NSCalendar currentCalendar].timeZone，发现后者无法正确获取到系统设置的当前地区。

以下测试在模拟器上进行，测试前都将地区设置为 China。

这是 iOS 11.4-12.4 的测试结果：
iOS 11.4 - 12.4

------------------------------------
(lldb) po [NSTimeZone defaultTimeZone]
Asia/Shanghai (GMT+8) offset 28800

(lldb) po [NSTimeZone localTimeZone]
Local Time Zone (Asia/Shanghai (GMT+8) offset 28800)

(lldb) po [NSTimeZone systemTimeZone]
Asia/Shanghai (GMT+8) offset 28800

(lldb) po [NSCalendar currentCalendar].timeZone
Asia/Shanghai (GMT+8) offset 28800

上面的结果显示，iOS 11.4 - 12.4 上，通过上述 API，能够正确获取到系统设置的时区（中国 +8 区）。
iOS 10-10.31 的测试结果如下：

iOS 10 - 10.31
------------------------------------
(lldb) po [NSTimeZone defaultTimeZone]
GMT (GMT) offset 0

(lldb) po [NSTimeZone localTimeZone]
Local Time Zone (GMT (GMT) offset 0)

(lldb) po [NSTimeZone systemTimeZone]
GMT (GMT) offset 0

(lldb) po [NSCalendar currentCalendar].timeZone
GMT (GMT) offset 0


上面的结果显示，iOS 10-10.31 上，无法正确获取到的系统当前时区，都会返回 GMT。
解决办法
用 weekdayWithCalandar 方法取代 weekday 方法。
NSCalendar* cal = [NSCalendar currentCalendar];
cal.timeZone = [NSTimeZone timeZoneWithName:@"Asia/Shanghai"];
NSInteger w = [baseDate weekdayWithCalendar:cal];
 

使用datepart计算weekday时我们会发现默认sql server返回的数字总是比实际的数值大一，如：2012-12-18是星期二，使用
select datepart(WEEKDAY,'2012-12-18');
得到值总是3，这是由于sql server默认星期天作为一周的第一天引起的。有人简单指出在计算传值时只需要把当前日期减去一天就可以避免这个问题了，虽然这种方法很简单却有潜在的问题，例如：当我们计算某一天属于某一年的第几周时，会使用形如:
select datepart(week,@Day);
的方式进行查询，此时依然会存在以周日作为一周开始而引起的问题，如2013-1-6是2013年的第一个周的周日，使用
select datepart(WEEK,'2013-1-6');
计算得到的却是2，如果在日期上减去一天又会导致另一个问题,如2013-1-1分明是2013年的第一周，如果减去一天得到就成了53，因为减去一天就回到了2012-12-31，这一天属于2012年的第53周。
正确的处理方式还是要设置sql server以哪一天作为一周开始，这个设置是通过修改全局变量DATEFIRST来实现的，如果想要以周一作为一周的开始，可以通过：
set datefirst 1;
来实现，更详细的解释可以参考：
http://technet.microsoft.com/zh-cn/interopmigration/aa259210

1、         建立枚举类型Weekday,假设今日为星期二，计算10天后为星期几。
#include<stdio.h>

typedef enum week{SUN,MON,TUE,WEN,THU,FRI,STA}Weekday;

int main(){
Weekday day,tenday;
int n;
day=SUN;
printf("输入数字：\n");
scanf("%d",&n);
tenday=(Weekday)((day+n+10)%7);
switch(tenday)
{
case SUN: printf("10天后是星期天\n"); break;
case MON: printf("10天后是星期一\n"); break;
case TUE: printf("10天后是星期二\n"); break;
case WEN: printf("10天后是星期三\n"); break;
case THU: printf("10天后是星期四\n"); break;
case FRI: printf("10天后是星期五\n"); break;
case STA: printf("10天后是星期六\n"); break;

}
return 0;

}