3 ms·
I wonder, is this more efficient than Microsoft's implementation? DateTime.Today.DayOfWeek; public DayOfWeek DayOfWeek { get {
by curiousCitizen 11y ago
I wonder, is this more efficient than Microsoft's implementation?
DateTime.Today.DayOfWeek;
public DayOfWeek DayOfWeek {
get {
Contract.Ensures(Contract.Result<DayOfWeek>() >= DayOfWeek.Sunday);
Contract.Ensures(Contract.Result<DayOfWeek>() <= DayOfWeek.Saturday);
return (DayOfWeek)((InternalTicks / TicksPerDay + 1) % 7);
}
}
public enum DayOfWeek {
Sunday = 0,
Monday = 1,
Tuesday = 2,
Wednesday = 3,
Thursday = 4,
Friday = 5,
Saturday = 6,
}
http://referencesource.microsoft.com/#mscorlib/system/datetime.cs,f6ea9c9a0d4b5e43 http://referencesource.microsoft.com/#mscorlib/system/dateti...
http://referencesource.microsoft.com/#mscorlib/system/dayofweek.cs http://referencesource.microsoft.com/#mscorlib/system/dayofw...
- Someone 11y agoThat's a different problem; it doesn't take year/month/day, but InternalTicks (and, nitpicking, doesn't appear to handle leap seconds, an issue that doesn't exist for functions taking ymd as input)
- brudgers 11y agoLeap seconds don't occur systematically, so there's no algorithm that can always determine the correct day of the week by the number of seconds or ticks from epoch. The algorithm of the subject line abstracts over leap seconds by referencing a calendar rather than a clock...i.e. a calendar being a document that names future times rather than an instrument that reports the current time.
- masklinn 11y agoIt's a different implementation, not a different concept. InternalTicks are how datetime data is represented in a C# datetime object (actually dateData which is a 64b bitfield: the first 62 bits are the internal tick, the last 2 bits are the kind).
- mark-r 11y agoSo all the hard work of converting year/month/day to InternalTicks is done at creation time, greatly simplifying the weekday calculation occurring later.