27

When I run:

TZ=Asia/Kolkata date --date="1/1/1906"

I get:

date: invalid date ‘1/1/1906’

Here I can find a good article on that: Calcutta Time

But the confusion also comes from the fact that 1905 was a valid date. Only 1906 wasn't. Any clue why?

chicks
  • 1,112
  • 1
  • 9
  • 27
15 Volts
  • 1,969
  • 2
  • 19
  • 34

1 Answers1

51

According to the time zone database (which gives references to other sources), on January 1, 1906, the local time¹ in Kolkata changed from an offset of 5:21:10 (“Madras time”) to an offset of 5:30 (India Standard Time), which means 8 minutes and 50 seconds were “lost” between December 31, 1905, and January 1, 1906. The latter starts at 00:08:50.

$ TZ=Asia/Kolkata date --date="1/1/1906 00:08:49"
date: invalid date ‘1/1/1906 00:08:49’
$ TZ=Asia/Kolkata date --date="1/1/1906 00:08:50"
Mon  1 Jan 00:08:50 IST 1906

Specifying the date only defaults to 00:00:00, which is invalid.

This happens whenever local time skips forward, e.g. when local time switches from “winter time” to “summer time” (or daylight savings time):

$ TZ=Europe/Paris date --date="03/29/2020 02:30"
date: invalid date ‘03/29/2020 02:30’

¹ For the time zone database’s purposes, “local time” here is defined as “railway time”, i.e. the time used for train timetables in the locality’s railway stations, and other railway-related events. See the India section of the database for Asia for details.

The time zone database considers that Wikipedia’s “Calcutta Time” (5:53:20) was used until 1870, when railway stations changed to Madras time. To add to the confusion, the time zone database refers to 5:53:20 as “Howrah Mean Time” (with some doubt), and “Calcutta Time” is defined with an offset of 5:53:28, in use until June 28, 1854 (again, for railway purposes).

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • 7
    It might be worth noting that this is an extremely common occurrence, with many countries changing offset twice a year (so-called "Daylight Savings Time"), but often pick the date and time of changeover carefully so that the "missing" time is less likely to be encountered. – IMSoP Sep 11 '20 at 08:25
  • @IMSoP that’s a good point, I’ve added that to the answer, thanks! – Stephen Kitt Sep 11 '20 at 08:50
  • 1
    similar: [Why is subtracting these two times (in 1927) giving a strange result?](https://stackoverflow.com/q/6841333/995714) – phuclv Sep 11 '20 at 14:18
  • 1
    @IMSoP, in this case, I suspect it was a change from solar time to zoned time. – Mark Sep 11 '20 at 22:21
  • 5
    Work with timezones in your code, they said. It will be fun, they said. – DeepSpace Sep 12 '20 at 10:47