Timezone not setting correctly


Using tablo-tools it jumps out my tablo is set Timezone America/New_York, which is the same response when querying your tablo /server/info - "timezone": "America/New_York",

I’ve tried to set my tablo’s time zone to US/Eastern, matching my PC.

I explicitly followed these instructions: https://support.tablotv.com/hc/en-us/articles/215173786-How-does-Tablo-handle-Daylight-Savings-Time-and-other-time-zone-changes- and Repeated by TabloSupport here Time in guide and what time a recording was made is off by 1 hour

In the end, it picks one from the region with the same UTC offset, not the zone explictly matching the device I used for the scan.

@TabloSupport is this post from Feb '17 dated? Or does tablo actually just get the offset from UTC? and use a name from tz database derived from my IP for timezone?
Is there a way to specifically set the timezone on my tablo?

Doesn’t the world revolve around negative and positive offsets from UTC.

Isn’t America/New_York the TZ database name.

You’ll have to do your own research. The TZ database isn’t an explicitly, legal, physical timezone.

For example, America/New_York represents most of the US eastern time zone;

You can find more here… https://mm.icann.org/pipermail/tz/2011-October/008090.html

Nevertheless… I followed the instructions to set the timezone on my tablo - why didn’t it set in compliance with the device I used?

Isn’t that article current? "This will reset your Tablo’s local time zone to match the one being used on the device running the channel scan. " It doesn’t say only to one in the tz database. Why did it change?

Maybe you should read about the list of TZ database names

Not just expect routine calls return your expectations for canonical name.

As an example Indiana has 3 TZ names because it resides in 2 timezones and 2 different day light savings zones.

It appears you misunderstood my question, and whey you ask your own - repeated – this is about how to follow the described instructions, to set the timezone on your tablo as explained in the instruction - set to the zone on the device used for the scan.

In the US - The time zone boundaries and DST observance are regulated by the Department of Transportation. Not a list for widely used by computer systems. Standard time zones in the United States are currently defined at the federal level by law 15 USC §260.

Not to discount the tz database, I am explicitly asking how to set the timezone as explained… what did I miss?

I you want to start your own topic for the first time ever about time zones - cool.

You have to think “Linux” and the zoneinfo db (I’m guessing, but think that’s the case).

Now… as for how it’s set?? Not sure if it can be changed (?) It could be using regional IP tricks… might get honed by initial setup for EPG. So the question would be in a non-subscribed Tablo, if it’s moved and sits on some sort of non-local network (weird VPN or something)… how would it know where you are? I guess you always have to provide “zip” (location) though even if not subscribed (??).

Edit: Maybe there’s enough data in the PSIP data of channels to deduce something?

How does Tablo handle Daylight Savings Time and other time zone changes?

This will reset your Tablo’s local time zone to match the one being used on the device running the channel scan.

man timedatectl

timedatectl set-timezone US/Eastern

Not sure they have the systemd. I used to use something dpkg-reconfigure tzdata

I’m familiar with tz database, but I set my time zone… how I want it to be (freedom of free and open software!) I’m not debating this, the instructions say I can set tablo to match my device’s zone… but I’m not getting it - what’s up with that?

So…just for clarification…you aren’t having any problem with time or anything, everything is working, you are just commenting on the difference between the text ‘US/Eastern’ and ‘America/New_York’?

I think your assumption is correct. They are using your machine to determine UTC offset, and then using a name out of some DB for that offset and displaying that as your TZ

It’s 2020 not 1969. The world has moved to standardization for portability.

Read Ietf rfc 7908 section 3.7.

Yes, just OCD. Following supplied instructions, not getting expected results.

Still misunderstanding the topic - you read the instructions supplied by tablo knowledge base support.

The read help to start your own topic😐

I understand your topic. But you start off complaining “technically not actually a physical timezones” .

If you don’t understand basics who knows what else is happening.

Just because they’re not the results YOU expect, doesn’t make them wrong. It’s actually setting the correct timezone, it’s just not reporting it the way you expect. Probably because the firmware is doing some sort of normalization to the TZ info, and then reporting it back in it’s preferred format.

I am in Mountain Time Zone, Tablo is reporting
“timezone”: “America/Denver”

…which is reported by my Windows OS as


When I ask Google it tells me

Mountain Standard Time
Time zone in Colorado Springs, CO (GMT-7)

(I won’t start a debate about GMT vs UTC)

Both OS and Google report that I’m 7 hours off of GMT/UTC…Table is giving me a ‘text’ that represents the same TZ as Google and my OS…

Are they the same words? No…but it’s the same timezone…so, the instructions could potentially be appended to say that it gets your UTC Offset from the client machine instead of ‘uses your timezone’…

But the net effect is you are being slightly sardonic…it’s working as expected.

1 Like

Yes, the end result is correct! Just not the way it was explained to ME. It’s not reporting it the way it’s (loosely) documented, from my device.

To be clear, US\Eastern is listed in the tz database.

I revised my original post to clarify setting tablo’s time zone to match scanning device, not just one in the region with the same offset – comparison would be not equal.

The only issue you’ve brought up is that you don’t like the name of the TZ that the Tablo is using. The Tablo doesn’t care about “physical timezone with legal boundaries”. All it cares is that the TZ info it’s using matches the one that the device it’s getting the data from is using. Even if it’s by a different name.