Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 2 12 LastLast
Results 1 to 10 of 12
  1. #1
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,905

    TimeZone DST handling

    I knew that I would have to face this at some point ... and it is now.

    The Perl DateTime module is not included by default in Slimserver distributions.
    So I am trying to find a way to determine if a specified "zone" is currently (or more correctly would be with a given date time) is Daylight Saving and then what is the offset.

    Reason:
    The software is running in numerous places around the world (LMS installations) - so I cannot rely on using local time and local DST since rules are different.
    The date/time stamp from the remote provider has no provided timezone information but (through configuration) it is known where in the world it is.

    e.g.
    Remote (radio station) says:
    2021-03-28 11:08:50
    which is
    2021-03-28 10:08:50 GMT - unixtime - 1616926130 - because the station is in UK and UK just moved to DST.

    I can cheat and put in my own local DST check to say ... this radio station is in UK and time between end of March and end of October so this is +1 time offset
    but I would prefer to do it with proper Perl modules.

    So - do I have to bundle DateTime module with my plugin and risk it being out of date or perhaps it relies on some stuff that is not Pure Perl so I end up with platform dependant binaries and the pain that causes?
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  2. #2
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,905
    I put in a temporary hack based on the local server being in DST.
    That will be OK for listeners who are in a timezone that changes at same time as UK ... but not nice.

    Code:
    			# HACK HACK HACK - emergency fix for DST while working on something better
    			my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime(time);
    			if ($isdst){ $entry->{tzhack} = 60; };
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  3. #3
    Senior Member
    Join Date
    May 2017
    Posts
    734
    Why not let user setup dst on his own?
    Lot's of device give you the opportunity to fill in how dst works in their country by first enable or disable dst and then fill in when and by how much for example:
    Dst start last week oktober at 3 am
    Dst stop last week March at 2am
    Difference 60 minutes.
    This way you're future proof if a country decide to change something.
    SqueezeBoxes: 1x Transporter (Living room) 1x SB2 (shed), 1x Radio (Kitchen), 1x Boom (Dining room), 1x piCorePlayer (jacuzzi), 1x piCorePlayer (Garden) 1x OSMC + Squeezelite (Movie room), 1x Touch (Study 2), few spare unit's
    Server: LMS on Pi3 7.9.1. on PcP 3.21
    Network: AVM Fritzbox, Netgear Smart Switch 24p, 3x Ubiquity

  4. #4
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,905
    I agree that it is one way of doing it - but would be a shame to put the onus on the end-user to do it when there is already a Perl module that, I think, can do it nearly automatically.
    Also - the details that the user would have to put in is when DST happens in UK (in my case with planetradio - but it would need to be reflect the timezone that the data provider is representing) not when it happens where the user is ... which they might now know so they would have to research it.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  5. #5
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    6,921
    Quote Originally Posted by Paul Webster View Post
    I knew that I would have to face this at some point ... and it is now.

    The Perl DateTime module is not included by default in Slimserver distributions.
    So I am trying to find a way to determine if a specified "zone" is currently (or more correctly would be with a given date time) is Daylight Saving and then what is the offset.

    Reason:
    The software is running in numerous places around the world (LMS installations) - so I cannot rely on using local time and local DST since rules are different.
    The date/time stamp from the remote provider has no provided timezone information but (through configuration) it is known where in the world it is.

    e.g.
    Remote (radio station) says:
    2021-03-28 11:08:50
    which is
    2021-03-28 10:08:50 GMT - unixtime - 1616926130 - because the station is in UK and UK just moved to DST.

    I can cheat and put in my own local DST check to say ... this radio station is in UK and time between end of March and end of October so this is +1 time offset
    but I would prefer to do it with proper Perl modules.

    So - do I have to bundle DateTime module with my plugin and risk it being out of date or perhaps it relies on some stuff that is not Pure Perl so I end up with platform dependant binaries and the pain that causes?
    I don't know how big is that module but you could add it just in your plugin. I've done that a couple of times, it fits as a sub-dir under you plugin repo.
    LMS 8.1.x on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  6. #6
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,905
    Quote Originally Posted by Paul Webster View Post
    Also - the details that the user would have to put in is when DST happens in UK (in my case with planetradio - but it would need to be reflect the timezone that the data provider is representing) not when it happens where the user is ... which they might now know so they would have to research it.
    pCP exposes timezone setup info to the end user with a link to a site that the strings can be copied from so I could do something like that.

    However, I know the timezone of the data so can easily default it to what will work for now.

    It does seem possible that UK will change its DST in next few years so making it configurable does seem reasonable but maybe I'll just set the default but not expose it in UI for now then if UK does change rules then it would be a simple edit to the plugin settings page to expose it or a one line change in the plugin source.
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  7. #7
    Senior Member
    Join Date
    May 2017
    Posts
    734
    Quote Originally Posted by Paul Webster View Post
    I agree that it is one way of doing it - but would be a shame to put the onus on the end-user to do it when there is already a Perl module that, I think, can do it nearly automatically.
    Also - the details that the user would have to put in is when DST happens in UK (in my case with planetradio - but it would need to be reflect the timezone that the data provider is representing) not when it happens where the user is ... which they might now know so they would have to research it.
    Aha, I thought the end users place.
    SqueezeBoxes: 1x Transporter (Living room) 1x SB2 (shed), 1x Radio (Kitchen), 1x Boom (Dining room), 1x piCorePlayer (jacuzzi), 1x piCorePlayer (Garden) 1x OSMC + Squeezelite (Movie room), 1x Touch (Study 2), few spare unit's
    Server: LMS on Pi3 7.9.1. on PcP 3.21
    Network: AVM Fritzbox, Netgear Smart Switch 24p, 3x Ubiquity

  8. #8
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,905
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

  9. #9
    Senior Member
    Join Date
    Dec 2020
    Posts
    120
    I'm somewhat puzzled what the challenge is supposed to be here. Are you saying that when I listen to a radio station somewhere on the other end of the Globe my player will adapt to the time as reported by that station rather than the one of my local LMS?

  10. #10
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    3,905
    IN this particular case the station puts out metadata as local time without any timezone information.
    So, for example, imagine that the broadcaster is in New York and the data says:
    Playing at 20:15 is X by Y
    So I configured things in the plugin to say that this broadcaster is 5 hours behind GMT and the plugin works out what timezone LMS is in (because the user has configured their LMS server correctly) and it works out that this LMS is running in Paris which is one hour behind GMT so that track plays at 02:15 the next day ...

    That was easy enough and the plugin handled it.
    The problem is when the listener and broadcaster switch to & from DST at different times in the year.

    In that case it is not sufficient to say that the broadcaster is 5 hours behind GMT because it is also necessary to know when the broadcaster changes to / from DST.

    So I needed to know that the broadcaster is in America/NewYork and then know the DST time change rules for that location.

    There are Perl modules that can do that for me ... but they are not installed with a standard LMS.

    What I have done is changed the plugin to use a 3rd-party service (not timeanddate.com but worldtimeapi.org) to perform a lookup of America/NewYork (or wherever) to find when DST switch next occurs and what the DST offset is and I cache the result.

    There is nothing for the user to do in this case. As long as the LMS server is configured with accurate time and local timezone information then all should be well.

    I have worked out a way to handle things when the date/time has not been set correctly on the LMS server (when it thinks it is 1970) but I have not implemented that part yet (and not sure that I will get around to it).
    Paul Webster
    http://dabdig.blogspot.com
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, Supla Finland, ABC Australia, CBC/Radio-Canada and RTE Ireland

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •