Time.zone() - I'm obviously missing something?

I am in the UK.
Our timezone is GMT - but currently a daylight saving time of +1 hour (British Summer Time) is in operation
I’m confused therefore as to why the code below returns unadjusted GMT hours? In the log example, it should return 10 but in fact returns 9 because it doesn’t think DST is in effect here - obviously I am missing something?

[From my Console page]

HourValue…Hour.Value=9 May 4th at 10:32:25 am

NOTE: No sign of the “DST is in effect” message from the code below.

Here’s my test code

void setup() {

void loop() {
  char buff[32];
  int hr=Time.hour();

  if (Time.isDST() == true) {
    sprintf(buff,"DST In Effect");
    Particle.publish("HourValue", buff, 60); 
  sprintf(buff,"Hour Value=%d",hr);
  // What's the hour value now...?
  Particle.publish("HourValue", buff, 60); 

  // This is a Test program only - don't loop again and snow the console.
  while (1) {

The docs says that setting a zone does not observer daylight saving.
I beleive you have to declare DST through setDSTOffset() and beginDST()
It’s not very clear in the doc, but this is what I understand from the firmware code.

[Edit] and also: Is isDST() supposed to be working now?


Hi Fabien,

Many thanks for the advice and the link. Am I right in thinking that from the comments by ScruffR on the post you linked, I might as well forget using the time functions to obtain a reliably accurate local time?

The time is accurate, but DST isn’t automatically reflected in that time. Your code will have to know when DST begins and ends. The best way I’ve come across in handling DST start/stop is to store an array of the start and stop times for each year and then trigger Time.beginDST() and Time.endDST() on those timestamps.

Okay, thanks. I’m sure I can do that.

It just seems a bit half-hearted that the particle cloud can give me a superbly accurate time (I checked and yes, it’s absolutely spot-on), but even when I tell it my timezone it can’t automatically tell me the local time representation! Maybe its not as easy as I think to maintain all those DST boundaries for anywhere in the world.

Anyhoo…Not a big deal, I will adopt the approach you suggest using the site linked below, which gives data for up to 2030


Many thanks guys.
Alan T