British Summer Time?

New Mycroft user here…

I’m struggling to get the correct time from Mycroft. I’ve set my location correctly in home.mycroft.ai - to a location in England.

We are currently under “British Summer Time”, which is our equivalent of DST, meaning the local time is currently GMT+1. However, when I ask the time, it reports back to me as GMT, so an hour behind. The location seems correct, as asking for a weather report gives accurate information.

Any idea how to get the time to report correctly? Or is there a website I can get correct info for my timezone to put into mycroft.conf?

Currently running Picroft on a Raspberry Pi 3B+

Hi @Category, welcome to the community :slight_smile:

I’m curious if you set your location to London does it still report the wrong time?

I’d say there are a few possibilities as to what is going wrong:

  • It’s putting you in the wrong timezone based on your location
  • It’s incorrectly determining the DST, either not including it or believing it’s not currently active.

In the short term, you can manually override the location/timezone settings via ~/.mycroft/mycroft.conf by adding the following block:

"location": {
    "city": {
      "code": "London",
      "name": "London",
      "state": {
        "country": {
          "code": "UK",
          "name": "United Kingdom"
        }
      }
    },
    "coordinate": {
      "latitude": 51.509865,
      "longitude": -0.118092
    },
    "timezone": {
      "code": "Europe/London",
      "name": "British Summer Time",
      "dstOffset": 3600000,
      "offset": 0
    }
  }

Just make sure to add a comma at the end of the preceding line.

The good news is that our new Home.Mycrof.ai that is currently in beta, has a completely new location system. We are hoping to iron out any final bugs in the coming weeks. So it’s probably easier to just use the above temporary fix and make sure it’s working as expected when the final production version of Home is released.

Thanks for the welcome!

I have changed my location to London in the current production version of home.mycroft.ai, but there was no change - still reporting as GMT, as opposed to GMT+1.

Still no change by editing mycroft.conf with the above either. I think it may be due to an error in how the DST is handled … I believe the way the UK handles this is backwards to the US - we change our clocks from the “true” time during the summer months, and the US change during the winter months.

Guess I’ll try the new home.mycroft.ai beta, and see if that helps…

Why don’t you just use the local tzdata though? That reports the correct time for me on the command line!!!

Hey, I just remembered that there’s a location setting under each device.

Can you check that this is set correctly and remove the mycroft.conf change?

If you mean setting under each device in home.mycroft.ai, thats how it was set up.

I’ve just reverted the mycroft.conf changes, and updated that page, and same result - still just gives GMT time, not BST

Hmmmm, there must be something else going on as if I change my location it reports the correct time for London, UK.

If you ask “what is my timezone”, what do you get? I am getting:

The answer is 01:51:16 British Summer Time, Thursday, 25 April 2019

Does “what is my timezone” need a skill added to work?

The time is reported correctly on the laptop on which I’m running Mycroft in Sussex, but I can’t easily check an RPi at the moment. Assuming that the RPi doesn’t have a real-time clock it might be necessary to check what time it thinks it is using a shell, which should also indicate what the current timezone is.

MarkMLl

“What is my timezone” did get a response with the wolfram alpha fallback skill.

Here is the history of mycroft-cli-client from the shell:-

what is my timezone
“The answer is 21:10:10 British Summer
Time, Thursday, 25 April 2019”
what time is it
“eight ten”
[edited to make it display correctly on this forum]

Using the “date” command from the shell also works, seems to be an issue with the date and time skill…

I did notice that my previous attempt at using an overide mycroft.conf did threw some errors into the log (probably a comma in the wrong place), so I will have a play now and see if I can get that to function correctly.

In short - my Pi knows where I am, and what time it is, just that Mycroft hasn’t gotten the memo!!!

The Date and Time Skill uses Python’s standard datetime package and pytz for the timezone data. I’ve tried on a few devices but cannot seem to replicate it.

To help debug the Skill, could you add the following lines to the Date-Time Skill on your device at Line 141 just before the return statement of get_local_datetime()

print("dtUTC: " + str(dtUTC))
print("location: " + str(location))
print("tz: " + str(tz))
print(dtUTC.astimezone(tz))
print("get_local_datetime(): " + str(dtUTC.astimezone(tz)))

You can also set the timezone very directly in there by adding:
tz = self.get_timezone("Europe/London")

Would be very curious if that works, but I’m mostly interested in the output from the CLI of the above additions. We should be getting:

  • dtUTC as the current GMT
  • tz as Europe/London
  • dtUTC.astimezone(tz) should evaluate to +01:00
  • and then once converted to a string in the final line should be your local BST.

I’ve made those additions to the Date and Time skill… The output in the CLI client I recieved is:-

dtUTC: 2019-04-27 13:05:40.487506+01:00
location: None
tz: Europe/London
+01:00
get_local_datetime(): 2019-04-27 13:05:40.487506+01:00

tz seems to be showing correctly, and showing the “+01:00” in all relevant fields. But when I ask Mycroft what time it is, he say “it is one oh five” - still an hour out!

Almost seems like it isn’t adding the DTC correction…

For the dtUTC this should be outputting the time as GMT +00:00 rather than +01:00

So it seems as though dtUTC has had it’s timezone replaced with BST without modifying the time stamp. Meaning it see’s it’s UTC time as +01:00, so all times should theoretically be getting reported as -1hr from reality.

dtUTC is assigned by calling now_utc() which simply returns to_utc(datetime.utcnow()), unless it’s somehow having an incorrect dtUTC passed into get_local_datetime()

@forslund do you have any hunch as to what might be causing this?

I have no real clue at the moment. I did a quick test and the time for London seems correct to me when I ask for it.

It would be interesting to see the /var/tmp/mycroft_web_cache.json file. to see if you have the expected offset there.

@forslund the contents of my mycroft_web_cache.json is currently:-

{
  "updated_at": 1556370692358,
  "created_at": 1554495014471,
  "tts": {
    "module": "mimic",
    "mimic2": {
      "created_at": 1554495014528,
      "updated_at": 1556370692734
    },
    "marytts": {
      "created_at": 1554495014526,
      "updated_at": 1556370692737
    },
    "espeak": {
      "created_at": 1554495014531,
      "updated_at": 1556370692744
    },
    "mimic": {
      "created_at": 1554495014521,
      "voice": "ap",
      "updated_at": 1556370692740
    },
    "google": {
      "created_at": 1554495014516,
      "updated_at": 1556370692742
    },
    "fatts": {
      "created_at": 1554495014518,
      "updated_at": 1556370692748
    }
  },
  "time_format": "half",
  "system_unit": "metric",
  "stt": {
    "wit": {
      "created_at": 1554495014473,
      "credential": {
        "created_at": 1554495014473,
        "updated_at": 1556370692361
      },
      "updated_at": 1556370692361
    },
    "mycroft": {
      "created_at": 1554495014481,
      "credential": {
        "created_at": 1554495014481,
        "updated_at": 1556370692375
      },
      "updated_at": 1556370692374
    },
    "ibm": {
      "created_at": 1554495014499,
      "credential": {
        "created_at": 1554495014499,
        "updated_at": 1556370692366
      },
      "updated_at": 1556370692365
    },
    "google": {
      "created_at": 1554495014491,
      "credential": {
        "created_at": 1554495014491,
        "updated_at": 1556370692371
      },
      "updated_at": 1556370692370
    },
    "module": "mycroft",
    "openstt": {
      "created_at": 1554495014507,
      "credential": {
        "created_at": 1554495014507,
        "updated_at": 1556370692380
      },
      "updated_at": 1556370692379
    }
  },
  "skills": {
    "created_at": 1554495014533,
    "stop_threshold": 2.0,
    "updated_at": 1556370693334,
    "directory": "~/.mycroft/skills"
  },
  "enclosure": {
    "created_at": 1554495014537,
    "rate": 9600,
    "updated_at": 1556370693338,
    "timeout": 5.0,
    "port": "/dev/ttyAMA0"
  },
  "listener": {
    "updated_at": 1556370693336,
    "energy_ratio": 2.5,
    "channels": 1,
    "threshold": 1e-30,
    "multiplier": 1.0,
    "created_at": 1554495014534,
    "wake_word": "Hey Marvin",
    "sample_rate": 16000,
    "phonemes": "HH EY . M AA R V IH N ."
  },
  "location": {
    "created_at": 1542722378426,
    "city": {
      "created_at": 1542722378427,
      "state": {
        "country": {
          "created_at": 1486088331527,
          "updated_at": 1486088331527,
          "code": "GB",
          "name": "United Kingdom"
        },
        "created_at": 1486129437940,
        "updated_at": 1486129437940,
        "code": "England",
        "name": "England"
      },
      "code": "Westminster",
      "name": "Westminster",
      "updated_at": 1542722378427
    },
    "updated_at": 1542722378426,
    "timezone": {
      "updated_at": 1486088331710,
      "name": "Greenwich Mean Time",
      "created_at": 1486088331710,
      "offset": 0,
      "dst_offset": 3600000,
      "code": "Europe/London"
    },
    "coordinate": {
      "created_at": 1542722378515,
      "longitude": -0.127758,
      "updated_at": 1542722378515,
      "latitude": 51.507351
    }
  },
  "date_format": "DMY"
}

This is after changing my location to London in home.mycroft.ai an updating config - still giving the time incorrectly by an hour.

Well, I have managed to fix this. I updated the pytz package using pip, and it is now reporting the correct time.

My pytz was on the 2017 version, now it’s up to date the time is reported correctly for BST.

Thanks for looking into it @gez-mycroft & @forslund , got it sussed in the end!

Thanks for reporting back. I will keep this fix in mind if further issues arise.

Out of curiosity, what is the current pytz version?

No problem - info from pip is:-

Name: pytz
Version: 2019.1
Summary: World timezone definitions, modern and historical
Home-page: http://pythonhosted.org/pytz
Author: Stuart Bishop
Author-email: stuart@stuartbishop.net
License: MIT
Location: /home/pi/mycroft-core/.venv/lib/python3.5/site-packages
Requires:
Required-by: tzlocal, Babel, astral

Previous version was 2017.2

2 Likes