Forecasting

Observations on a Permanent Calendar: As Time Goes By

May 14, 2020

The common civil calendar used around the world is the Gregorian Calendar, which was adopted in 1582 to replace the Julian calendar. The impetus to replace the Julian calendar was that the dates were shifting with respect to the equinoxes. Both of these calendars are solar calendars; that is, they reckon time based upon the earth’s orbit around the sun. Because the earth’s orbit around the sun is not exactly 365 days, we also use leap years. In the Julian calendar, all years that are evenly divisible by 4 are leap years. In the Gregorian calendar, however, a year is a leap year if it is evenly divisible by 4, but not if it is divisible by 100, unless it is also divisible by 400. Thus, the year 1900 was not a leap year, but 2000 was a leap year. This small adjustment has helped to keep the Gregorian calendar in sync with the seasons.

For most purposes of reckoning time, the Gregorian calendar is sufficient, providing a year that is 365.2425 days long on average, but, the calendar is odd for a number of reasons.

  1.  The days of the week move around with respect to the date. That is, Jan. 1 is sometimes a Monday and it is sometimes a Tuesday.
  2. The number of days per month ranges from 28 to 31 in a less-than-obvious way. You need your knuckles or a catchy song to remember the right number: “Thirty days has September… April, June and November…”
  3. The adjustment for leap year (i.e. Feb. 29) happens in the second month. Is that really the best place for it? It seems like a more obvious candidate would be…maybe the last day of the year?
  4. October is the 10th month, even though the prefix ‘oct’ comes from the Greek word for eight. December is the 12th month, even though the prefix ‘dec’ comes from the Greek word for ten (this particular issue just offends my aesthetic sensibilities).


To be fair, there are historical and esoteric reasons to explain all of these and you can research them if you are so inclined.

From the perspective of energy forecasting, the Gregorian calendar creates challenges primarily because of the dates moving with respect to the weekday. While we have many holidays in the U.S. that are tied to a particular weekday (e.g., Memorial Day and Labor Day are always on a Monday), there are other holidays that are tied to particular dates (i.e., Independence Day is always on July 4 and Christmas is always on December 25), whose energy impacts differ depending upon the weekday on which they fall. This particular issue causes no small amount of consternation and hand wringing.

Professors Steve Hanke and Richard Henry at Johns Hopkins have formulated an alternative calendar, not surprisingly called the Hanke-Henry Permanent Calendar (as a side note, I’ve always wanted something named after me: The Simons Coefficient, The Simons Statistic or the Rich Effect. But I digress). The salient features of their calendar are:

  1. Jan. 1 is always a Monday. Thus, holidays always fall on the same weekday: July 4 is always on a Thursday and Christmas is always on a Monday.
  2. The year is broken into four quarters – each of which has three months – with days per month being 30, 30 and 31 (for a total of 91 days) respectively within the quarter.
  3. To keep the calendar in-sync with the seasons (i.e., the same reason we have a leap year), there is an extra weeklong month (which they call Xtr) after December, when the corresponding Gregorian year starts or ends on a Thursday.
  4. October is still the 10th month rather than the 8th month, but I can live with that.


In our arena, these features alleviate the problem of varying a holiday’s load-impact due to shifting weekdays. From a long-term forecasting perspective, it helps remove the problem with months having varying numbers of weekdays and weekends. And, what about that bump in your energy forecast for leap year Februarys? While it is correct to put more energy in the 29-day February (because it has 3.57% more days than a 28-day month), it always creates an oddity that requires some explanation. February now has 30 days always. Problem solved.

There are a number of other features that I encourage you to investigate on your own. One of their suggestions is that we all use the same clock; everybody would be on UTC (Universal Coordinated Time), although local areas would still operate based on their location. For instance, people in the Eastern Time Zone would wake in the morning at roughly 11 a.m. UTC (which corresponds to 6 a.m. EST). While this seems convenient and unambiguous for international business (“I’ll call you tomorrow at 12 p.m. UTC”), it still seems confusing to me.

Now, this is about as likely to be adopted as we are to cease using the QWERTY keyboard, to convince the British to drive on the right side of the road, or to adopt the metric system in the U.S. Still, it is an outstanding idea that is worthy of attention and I sincerely applaud Hanke and Henry for their noble efforts.
 

Kesalahan terjadi ketika Memproses Template.
The following has evaluated to null or missing:
==> authorContent.contentFields  [in template "44616#44647#114455" at line 9, column 17]

----
Tip: It's the step after the last dot that caused this error, not those before it.
----
Tip: If the failing expression is known to legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??
----

----
FTL stack trace ("~" means nesting-related):
	- Failed at: contentFields = authorContent.content...  [in template "44616#44647#114455" at line 9, column 1]
----
1<#assign 
2	webContentData = jsonFactoryUtil.createJSONObject(author.getData()) 
3	classPK = webContentData.classPK 
4/> 
5 
6<#assign 
7authorContent = restClient.get("/headless-delivery/v1.0/structured-contents/" + classPK + "?fields=contentFields%2CfriendlyUrlPath%2CtaxonomyCategoryBriefs") 
8contentFields = authorContent.contentFields 
9categories=authorContent.taxonomyCategoryBriefs 
10authorContentData = jsonFactoryUtil.createJSONObject(authorContent) 
11friendlyURL = authorContentData.friendlyUrlPath 
12authorCategoryId = "0" 
13/> 
14 
15<#list contentFields as contentField > 
16   <#assign  
17	 contentFieldData = jsonFactoryUtil.createJSONObject(contentField)  
18	 name = contentField.name 
19	 /> 
20	 <#if name == 'authorImage'> 
21	    <#if (contentField.contentFieldValue.image)??> 
22	        <#assign authorImageURL = contentField.contentFieldValue.image.contentUrl />	 
23			</#if> 
24	 </#if> 
25	 <#if name == 'authorName'> 
26	    <#assign authorName = contentField.contentFieldValue.data /> 
27			<#list categories as category > 
28         <#if authorName == category.taxonomyCategoryName> 
29				     <#assign authorCategoryId = category.taxonomyCategoryId /> 
30				 </#if> 
31      </#list> 
32	 </#if> 
33	 <#if name == 'authorDescription'> 
34	    <#assign authorDescription = contentField.contentFieldValue.data /> 
35			 
36	 </#if> 
37	  
38	 <#if name == 'authorJobTitle'> 
39	    <#assign authorJobTitle = contentField.contentFieldValue.data /> 
40			 
41	 </#if> 
42 
43</#list> 
44 
45<div class="blog-author-info"> 
46	<#if authorImageURL??> 
47		<img class="blog-author-img" id="author-image" src="${authorImageURL}" alt="" /> 
48	</#if> 
49	<#if authorName??> 
50		<#if authorName != ""> 
51			<p class="blog-author-name">By <a id="author-detail-page" href="/w/${friendlyURL}?filter_category_552298=${authorCategoryId}"><span id="author-full-name">${authorName}</span></a></p> 
52			<hr /> 
53		</#if> 
54	</#if> 
55	<#if authorJobTitle??> 
56		<#if authorJobTitle != ""> 
57			<p class="blog-author-title" id="author-job-title" >${authorJobTitle}</p> 
58			<hr /> 
59		</#if> 
60	</#if> 
61	<#if authorDescription??> 
62		<#if authorDescription != "" && authorDescription != "null" > 
63			<p class="blog-author-desc" id="author-job-desc">${authorDescription}</p> 
64			<hr /> 
65		</#if> 
66	</#if> 
67</div> 

Related Articles