DayOfWeek Enumeration (System)

Is it safe to make assumptions about the underlying int values of the enum? As in, are they fixed in documentation or not?

The Underlying Values

Note that, with rare exceptions, we don't document the underlying values of enumeration members. Part of the value of enumerated constants is that they free developers from having to work with numeric values and instead allow them to work with more intuitive names.

That said, changing the underlying values of enumeration members is a major breaking change. Because the .NET Framework aims at maximizing compatibility from version to version going forward, and also because a good deal of customer code uses the underlying value of the DayOfWeek enumeration to retrieve localized day names from the DateTimeFormatInfo object, it is safe to assume that the underlying values of the DayOfWeek enumeration will never change.

--Ron Petrusha
Common Language Runtime User Education
Microsoft Corporation

I mean, should I be running on a German-based OS, will DayOfWeek return, instead of Saturday, Samstag? What about the order of the days (the first day of the week in Germany is Monday)

DayOfWeekEnumeration and Regional Settings

DayOfWeek is an enumeration. Both the names and the values of its members remain constant across cultures. The enumeration is intended for use in methods, such as the Calendar.GetWeekOfYear method, that specifies the first day of the week as a method argument. Enumerations are not dependent on regional settings.

If you are interested in the culture-sensitive names of the days of the week or in the first day of the week for a particular culture that uses a particular calendar, use a DateTimeFormatInfo object that reflects the settings for a particular culture. For example, to get the localized names of the week for the German (Germany) culture and to determine the first day of the week, you can use code similar to the following:

using System;
using System.Globalization;
public class Example
{
   public static void Main()
   {
      CultureInfo german = new CultureInfo("de-DE");
      DateTimeFormatInfo dtfi = german.DateTimeFormat;

      Console.WriteLine("Days of the week for the {0} culture:",
                        german.Name);
      for (int ctr = 0; ctr < dtfi.DayNames.Length; ctr++)
         Console.WriteLine("   {0,-12}{1}", dtfi.DayNames[ctr],
                           dtfi.DayNames[ctr] == dtfi.DayNames[(int)dtfi.FirstDayOfWeek] ? 
                                "(First Day of Week)" : "");                        
   }
}

--Ron Petrusha
Common Language Runtime Developer Content
Microsoft Corporation

int myDay6 = 6;
DayOfWeek dw6 = (DayOfWeek)myDay6;
Console.WriteLine(myDay6 + " " + dw6.ToString()); // will print "6 Saturday"
int myDay7 = 7;
DayOfWeek dw7 = (DayOfWeek)myDay7;
Console.WriteLine(myDay7 + " " + dw7.ToString()); // will print "7 7"

This Is Not an Error

The underlying values of the DayOfWeek enumeration range from 0 (for DayOfWeek.Sunday) to 6 (for DayOfWeek.Saturday). The value of dw7, therefore, does not correspond to the underlying value of a member of the DayOfWeek enumeration. In this case, the call to the ToString method will always return the string representation of a number, rather than a string containing the name of the enumeration member.

More generally, a major justification for the use of enumeration types is that they free developers from having to work with the underlying values of enumerations, which in most cases are symbolic numbers. Rather than casting from an integer to the enumeration type, a much better practice in this case is simply to assign the DayOfWeek variable an enumeration value rather than an integer value. For example:

      DayOfWeek myDay6 = DayOfWeek.Saturday;
      Console.WriteLine("{0:D} {0:G}", myDay6);
      DayOfWeek myDay7 = DayOfWeek.Sunday;
      Console.WriteLine("{0:D} {0:G}", myDay7);

If you want to ensure that an enumeration variable is not assigned an out-of-range value, you can call the Enum.IsDefined method to validate an enumeration's underlying value.

--Ron Petrusha
CLR Developer Content Team
Microsoft Corporation