On 20 September 2026 at 02:00, Morocco moved its clocks back to 01:00 and stayed there. The country is now on GMT (UTC+0) all year. The legal basis is decree 2.26.530, published in Official Bulletin no. 7521, which repeals the 2018 decree that created permanent GMT+1.

What changed for developers

From 2018 to 2026, Morocco was one of the odd cases in time zone handling. It sat on UTC+1, then dropped to UTC+0 during Ramadan, on dates that moved every year. That rule is gone.

The IANA time zone database carries the change from release 2026c, dated 8 July 2026, for two zones: Africa/Casablanca and Africa/El_Aaiun.

A one-line test

Ask your runtime for the offset on a date after the change:

from datetime import datetime
from zoneinfo import ZoneInfo

print(datetime(2026, 12, 1, 12, tzinfo=ZoneInfo("Africa/Casablanca")).utcoffset())
# 0:00:00 means your data is current. 1:00:00 means it is old.

We ran this on one of our own machines while writing this post. It printed 1:00:00, because Python was using tzdata 2026b.

Where it still goes wrong

• Bundled time zone data. Python's tzdata package, npm packages and container images ship their own copy, which only changes when you update them.
• Old operating system images. A server that has not been patched since before July 2026 keeps the old rule. On our own Windows host, we stopped trusting the system zone data for Morocco and work from UTC directly.
• Hard-coded Ramadan tables. Code that switches Morocco to UTC+0 during Ramadan can be removed for dates from 20 September 2026. Keep it for historical dates.
• Static text. Travel guides and company pages often say "Morocco is GMT+1". When we checked about 100 pages on 31 October 2026, we found 28 sites still saying so, including some live clocks.

Time differences now

The full table and sources are on our page: Time in Morocco: GMT all year since 20 September 2026.

What we measure

Every recruitment notice has an application deadline. After it, the administration publishes up to four lists: the shortlist for the written exam, the shortlist for the oral, the final results and sometimes a waiting list. Since 31 July 2026 we record the day each list appears on the official portals and compute the delay in calendar days after the deadline.

The numbers (snapshot of 30 October 2026)

• Shortlist for the written exam: median 13 days after the deadline (first quartile 7, third quartile 27, n = 1,315 lists).
• - Shortlist for the oral: median 27 days (18 to 35, n = 899).
• - Final results: median 37 days (24 to 45, n = 310).
• - Waiting list: median 37 days (32 to 47, n = 80).

By administration the spread is wide: the universities of Agadir and Marrakech shortlist in 6 to 9 days, others take a month. The per-employer table is on the source page and updates daily.

Caveats

These are preliminary figures and they are biased towards short delays: a list that has not appeared yet is not in the sample, so the slow cases are under-represented until they close. They are not official dates and should not be read as commitments.

Get the data

• Live tables, method and limits (French, Arabic version linked): https://www.wadifa-info.com/fr/delai-resultats-concours-maroc
• - The notices themselves, as JSON with no key: https://www.wadifa-info.com/en/api

Free to reuse with a link (CC BY 4.0). Corrections: contact@wadifa-info.com.

The problem

Almost every holiday API and library (python-holidays, date-holidays, Jollyday, Nager.Date) computes Islamic holidays from the Saudi Umm al-Qura calendar, or from a generic astronomical table. Morocco does not use either. The Ministry of Habous and Islamic Affairs announces the start of each lunar month on the evening of the 29th, after its own sighting committee reports. The announcement is final and the public holiday follows it.

So the question was simple: how often does Morocco differ from Saudi Arabia, and by how much?

What we did

We collected the official Moroccan date of 1 Ramadan, Eid al-Fitr, Eid al-Adha, 1 Muharram and Mawlid for every year from 2000 to 2026: 135 dates. Each one comes from a press report of the ministry's announcement (MAP, Medias24, Le360, Hespress, TelQuel, SNRT), and for 2000-2013 from the ICOP archive, which records the first official day per country. Nothing is computed. Four dates we could not source were dropped rather than estimated.

Next to each Moroccan date we put the Saudi date and the difference in days.

What the numbers say

• Morocco was at least one day behind Saudi Arabia 91 times out of 135.
• - The two countries were on the same day 44 times.
• - Morocco was never ahead.
• - Since 2020 the gap has been the rule: every Eid al-Adha and every Mawlid from 2021 to 2025 fell a day after the Saudi date.

Against the libraries: python-holidays 0.107 and date-holidays 3.38 are one day early for 71 to 73 of the 110 dates we could compare; Jollyday for 73; the Ruby holidays gem only knows the two Eids; Nager.Date has no religious holidays for Morocco at all.

Why it matters in practice

If you run payroll, schedule deliveries or publish a calendar for Morocco, "Eid al-Fitr: 20 March 2026" from a library is a guess that is wrong about two times out of three. For Morocco the honest answer before the announcement is "20 or 21 March, confirmed on the evening of the 19th".

Get the data

• The full table with a source for every row, CSV under CC BY 4.0: https://www.wadifa-info.com/en/morocco-islamic-holiday-dates-2000-2026
• - Current-year holidays as JSON, no key: https://www.wadifa-info.com/api/v1/jours-feries
• - The same dataset on Hugging Face: https://huggingface.co/datasets/wadifainfo/morocco-religious-holidays-2000-2026

If you maintain a holiday library and want the Morocco-specific dates, the CSV is the file to import. Corrections welcome at contact@wadifa-info.com.

Most of these papers arrive as photos or scans. A page that is only an image can't be searched, can't be quoted in a page description, and tells a search engine almost nothing. So every page needs its text. This post covers how we OCR'd the whole library on one Windows machine with Tesseract, and the four traps that made "done" turn out to be not done.

Setup: Tesseract 5 with the right language data

Tesseract 5.4 installs on Windows with one command:

winget install --id UB-Mannheim.TesseractOCR -e

It ships with English only. Arabic and French data come from the tessdata_fast and tessdata_best repositories, and you point Tesseract at them with --tessdata-dir (handy when you can't write to Program Files).

We measured the options on a real bilingual page, counting recognised Arabic and Latin characters:

Two lessons: the best Arabic model is clearly better on photographed pages, and a single-language model mangles the other script, so bilingual pages need both (-l ara_best+fra).

Preprocessing that actually helped

Three cheap steps, in Pillow, before every page:

def prep(src):
    im = Image.open(src).convert("L")                  # grey
    if im.width < 1800:                                # small phone photos
        im = im.resize((im.width * 2, im.height * 2), Image.LANCZOS)
    return ImageOps.autocontrast(im)

Then tesseract page.jpg stdout -l ara_best+fra --psm 6. Page segmentation mode 6 ("a single uniform block of text") beat the automatic mode on exam sheets, which are mostly dense paragraphs and numbered questions.

On the first pass this filled 286 of 289 papers that had no text, median about 2,900 characters per paper.

Trap 1: photographed pages that return only our own footer

A few phone photos came back with exactly one line: the footer we add to every page. Tesseract found no text blocks at all, at any --psm, at any scale. The page wasn't blurry; it had uneven lighting, so a global threshold turned half the sheet into one dark blob.

The fix was an adaptive threshold, done in Pillow without OpenCV: compare each pixel with a heavily blurred copy of the page, and keep only what is darker than its local background.

bg   = im.filter(ImageFilter.GaussianBlur(20))
diff = ImageChops.subtract(bg, im)            # ink is darker than the local background
th   = diff.point(lambda v: 0 if v > 12 else 255)

We now try four variants per page (plain or adaptive, --psm 4 or 6) and keep the one with the most real words. "Real word" is deliberately crude: Arabic words of three letters or more, and Latin words of three letters or more that contain a vowel. Our worst three papers went from a single footer line to 4,800–5,600 characters each.

Scoring trap inside the trap: we first stripped footer lines before scoring the old text. A one-line OCR result is the footer line, so stripping it scored the old text as zero and every comparison looked like a huge win. Strip the footer phrase, not the line.

Trap 2: a page cap we forgot about

The first script had MAX_PAGES = 8 to keep test runs short. It never came out. Fifty-eight papers longer than eight pages had pages 9+ silently skipped, about 400 pages in total.

What caught it was a simple health check: for each paper, compare the number of images we publish with the highest page marker in its text. Our OCR writes a marker between pages (— صفحة N —), so a 12-page paper whose text stops at page 8 is easy to spot. We now run that check after every import.

Trap 3: papers that are only half there

This one wasn't an OCR bug; OCR found it. Many official papers print their own footer: Page 2 sur 5, or الصفحة 2 من 5. If the paper says "page 1 of 9" and we publish 4 images, we are missing pages.

Matching that pattern across the library found nine incomplete papers. One of them showed only "Page 2 sur 2": visitors were opening the paper halfway through, at exercise 3.

Two things made the detector usable:

1. Never match a bare N/M. Moroccan exams are marked out of 20 or 10, so 14/20 is a score, not a page number. The naive pattern produced 34 candidates, almost all wrong. Only explicit forms count: Page N sur M, Page N | M, الصفحة N من M.
2. Read the context. "Répondre sur le document réponse (page 06/10)" is a cross-reference, not a footer.

Trap 4: duplicates that look different, and different papers that look the same

The same paper often reaches us twice: a clean PDF and a phone photo of a printout, or the same engineering-school subject adapted for two streams. Image hashing on a page region gave false positives (shared headers), and comparing only the first 3,000 characters did too: the adapted version shares the opening, then diverges.

What worked was comparing the full OCR text at the word level:

from difflib import SequenceMatcher
same = SequenceMatcher(None, a.split(), b.split()).ratio() >= 0.84

Above 0.84 it was always a true copy in our checks; below it, a genuinely different paper. Seven copies were hidden this way.

Where it ended up

• Every published paper has text, except a handful of genuinely unreadable photos that we leave empty on purpose rather than fill with noise.
• Each paper page shows the transcription in a collapsed "text of the questions" box, with a note that it was extracted automatically and the images remain the reference. Candidates can search and copy the questions, and search engines can finally read what each paper covers.
• The same text drives our duplicate check when new papers come in.
• The health checks (page count vs. last marker, very short texts, printed "Page N sur M") run after every batch.

If you're digitising scanned documents in Arabic, or any mixed-script material, the short version is: use the best model, always pair the scripts, preprocess, keep an adaptive-threshold fallback, and never trust "100% done" until a check you didn't write for the happy path agrees.

The papers themselves are free to browse at wadifa-info.com.

Written with the help of an AI assistant from our own code and logs; all figures are from our production data.

This post covers the parts that were harder than expected: fitting text of unknown length, Arabic right-to-left, picking a layout without randomness, and not letting the endpoint become an abuse vector. The stack is plain ASP.NET MVC and System.Drawing (GDI+).

One card model, three formats

The renderer takes a small object (institution, job title, specialty, number of posts, deadline, language) and a canvas size:

• og 1200×630 for link previews
• sq 1080×1080 for social posts
• pt 1080×1350 for portrait feeds

Nothing in the layout is hard-coded to a size. Everything is expressed in a unit U = min(width, height) / 100, and the layout is decided from the shape: a wide canvas gets a text column with an art panel beside it, a tall canvas gets an art band on top with the text stacked below.

bool wide = W >= H * 1.5f;
var c = new WfCtx(g) { U = Math.Min(W, H) / 100f, Rtl = d.Rtl };

Adding the portrait format later was one line in the size switch. The layout code did not change.

Text that always fits

A job title can be "Technicien" or a 120-character ministry name. The rule we settled on is: shrink, then wrap, then drop optional rows, then ellipsis.

WFit tries font sizes from the maximum down to the minimum, wraps at each size, and returns the first size where the text fits the allowed number of lines:

static Font WFit(WfCtx c, string text, FontFamily fam, float maxPx, float minPx,
                 float maxW, int maxLines, out List<string> lines)
{
    float step = Math.Max(2, (maxPx - minPx) / 10);
    for (float px = maxPx; px >= minPx; px -= step)
    {
        var f = c.F(fam, px); var ls = WWrap(c, text, f, maxW);
        if (ls.Count <= maxLines && ls.All(l => WTW(c, l, f) <= maxW * 1.001f))
        { lines = ls; return f; }
    }
    // still too long at the minimum size: keep maxLines and end with an ellipsis
    ...
}

One case survives all of that: a single word wider than the column at the minimum size. For that, the draw call condenses the line horizontally instead of overflowing:

float w = WTW(c, s, f), sx = (maxW > 0 && w > maxW) ? maxW / w : 1f;
c.G.TranslateTransform(left, y);
if (sx < 1) c.G.ScaleTransform(sx, 1);

A slightly condensed word looks far better than a clipped one.

Arabic and French in the same card

Two things made bilingual rendering work:

1. Direction per string, not per card. A card in Arabic can contain a Latin acronym, and a French card can contain an Arabic institution name. Each string is measured and drawn with a right-to-left StringFormat if it contains Arabic characters, and left-to-right otherwise. GDI+ then does the shaping and joins the letters correctly.
2. One font family for both scripts. We load Tajawal (an open-licence family with Arabic and Latin glyphs) from the app's own folder with PrivateFontCollection, so the server does not need any font installed. Arabic lines also get more line height (1.30 against 1.14), because the letterforms need it.

The whole layout mirrors for Arabic: the art panel, the alignment anchor, the arrow in the call-to-action button.

One GDI+ detail to know: Font and StringFormat objects are not thread-safe, so they live in a per-request context object, never in static fields.

Variety without randomness

A feed where every card looks identical is dull, but a card that changes every time it is fetched breaks caching and confuses people who share it. So the template is chosen from a stable hash of the job:

static uint WfHash(string s)
{ uint h = 2166136261; foreach (char ch in s ?? "") { h ^= ch; h *= 16777619; } return h; }

t = cands[(int)(seed % (uint)cands.Count)];

The candidate list depends on the data. A card only gets the "key figure" template if there is a real figure to show (number of posts, days left when the deadline is within five days). There is no invented urgency: the status badge is computed from the real deadline.

The background art is vector, drawn in code: a network for IT jobs, arches for teaching, a pulse line for health, an eight-point star lattice as the default. Recently we added a "document" drawing (a white sheet with a CV-like skeleton) for pages that are about a document, such as CV and cover-letter templates.

Do not render arbitrary text on your domain

Generic pages (guides, salary tables) also get a card, built from the page title. The title travels in the image URL, which means anyone could request an image with any text on it, served from our domain. So the title is signed with an HMAC, and the endpoint refuses anything whose signature does not match:

if (t.Length == 0 || t.Length > 120 || !string.Equals(s, WfSig(t), StringComparison.Ordinal))
    return Redirect("/img/og-default");

If you build an image endpoint that takes text from the query string, do this from day one.

Caching

Rendering takes real CPU, so each image is written to disk under a key made of every input that affects the pixels, and served as a static file afterwards. Cards near a deadline include the date in the key, because their "N days left" badge changes daily. Everything else is sent with a one-week cache header.

What we would do differently

• System.Drawing is Windows-only in modern .NET. It suits our hosting, but on Linux we would start with SkiaSharp.
• We would design the portrait format first. Link previews are forgiving; tall formats expose every spacing mistake.
• An earlier, unrelated endpoint on the site accepted unsigned tokens and had to be fixed after an audit. That is why this one was signed from its first version.

You can see the result on any page of the site, for example the civil-service salary grid: its link preview is one of these cards.

Have you built server-side image generation with right-to-left text? We would like to hear how you handled mixed-direction lines.