[Updated to using JST time to correct bug.]
Nah, we know this is totally useless, especially when there are many websites showing metal zone schedules in more details, in much better/friendlier format and when we only run Arena versions of metal zones. We just wanted to practise. Maybe it is good to have a little desktop version of metal zone schedule? Here we use JST time which is UTC+9 because we got the data from Famitsu and using other timezone like UTC may result in having two MZK7 in one day or zero in another, which is a great hassle. Thus it is your task to shift the hours to reflect your own time zone. Yes, about user-friendliness, we are bad.

Schedule for MZK (JST time)
#+NAME:MZK
#+Constants: basedate=<2016-08-02>;
| 0 | 1 | 2 | 3 |  4 | 5 |  6 |  7 |  8 |  9 |
| 9 | 17| 12| 7 | 19 | 8 | 10 | 22 | 11 | 17 |

|      | <13>          |           |           |
| Day# | Date          | MZK6 Hour | MZK7 Hour |
|------+---------------+-----------+-----------|
|    1 | <2016-10-22>  |         9 |        17 |
|    2 | <2016-10-23=> |        17 |        12 |
#+TBLFM: @[email protected] + 1::$1=($2-$basedate)%10::$3='(org-lookup-first (% (+ $1 6 -7) 10) '(remote(MZK,@1$<[email protected]$>)) '(remote(MZK,@2$<[email protected]$>)));N::$4='(org-lookup-first (% (+ $1 7 -7) 10) '(remote(MZK,@1$<[email protected]$>)) '(remote(MZK,@2$<[email protected]$>)));N

Usage:

To see today's Metal Zone hour for MZ6K or MZ7K, first enter today's date on row 3. Here <2016-10-22> is entered. Then C-c C-c on the line #+TBLFM. The day number and the hours will be computed. The schedule for the next day is also computed. (Maybe also C-c C-c on #+NAME and #+Constants lines?)

Some explanation on the code. This is for org-mode in Emacs. We have two tables. The first one is named MZK. It is for looking up values. If we knew how to have a vector variable we would not need a look-up table at all. (Need more practice ;_; ) We define a constant, basedate, to be used in the computation. The schedule is determined by the day number mod 10. It so happens that we know that <2016-08-02> is day 0 mod 10. For the second table, <13> is used to control column width, so that the table appears OK in this blog.

For the formulae:

Add 1 day to the one on the previous row. This is a field formula.

@[email protected] + 1

Compute the day number mod 10.

$1=($2-$basedate)%10

Look up the hour corresponding to the day number. In other words, find the match in the first row of table MZK and see what it is there in the second row of that column. The ;N part means that we treat the contents in the cells as numbers rather than strings. This is a column formula. The one for MZ7K is similar, with just an offset.

$3='(org-lookup-first (% (+ $1 6 -7) 10) 
'(remote(MZK,@1$<[email protected]$>)) '(remote(MZK,@2$<[email protected]$>)));N

FAQ:

  • What the hell is (% (+ $1 6 -7) 10)? Written in less lispy way, this is ($1 + 6 - 7)%10. Here 6 corresponds to the 6 in MZ6K. This is the correct index used in determining the hour of Metal Zone King 6.
  • What the hell is @2$5 for example? Check org-mode manual for how one references cells for more details. @2$5 means row 2 column 5. Cell indices are 1-based BTW.
  • Why is there an extra = in <2016-10-23=>? Autocomputed date value contains a day signature, but here column width is set too narrow to show it. When there is enough space, one gets  <2016-10-23 Sun>. We are sure there is a way to hide the Sun, but we are just lazy and find it bearable.

Probably we don't need to record the intermediate step for the day number mod 10. Anyway this is just a personal study for org-mode.