Time Zones and DST (again)

[BeanAnimal]

@Gaël @Vinny@GHLUSA

I am asking again (as I do every dix months). Can either of you definitively explain the time settings on the P4?
They make absolutely zero sense to me and I am tired of fighting this thing for a month every six months when time zones changes.

My P4 is set to use NTP
I am on the east cost of the United States of America.
My timezone is currently UTC -4
The current time is 7:27PM and UTC time is 11:27PM
My P4 shows the time:
6:27 PM
UTC -4
Change from Winter (standard) to summer time = TRUE
Days to process = 7

DST change has come and gone in both EU and US
Why is my P4 time still an hour off?

1 - What does the UTC setting actually do? It appears to have no immediate affect, my time is still an hour off.
2 - what in the world does "change from winter (standard) time to summer time" actually do then?
3 - Why does the number of days to process the change actually do then?
4 - Why does a product sold both in the EU and in the US have hard coded EU DST dates only?
5 - Why does token based reporting return local time instead of universal time? This too is a mess. Because the exported data from the P4 is an hour off and therefore so is the timestamp on the reporting, but even if the P4 time was right; once a year you lose an hour of reporting and once a year you overwrite an hour of reporting based on this mess. If there is a token for TIME output, then it either MUST contain the TZ (difference from UTC) or be in UTC.

Trying not to be unreasonable here, but this really is a mess that should not be that hard to fix.

Honestly trying not to be unreasonable here, but we worked out how to manage time logic as it relates to reporting and computers, data loggers, etc. decades ago. Everything should be calculated and acted upon in UTC and only translated to local time for display purposes.

I am honestly extremely frustrated over this.

 

[Dave-T]

@Gaël @Vinny@GHLUSA

Everything should be calculated and acted upon in UTC and only translated to local time for display purposes.

I am honestly extremely frustrated over this.

Exactly. I just banged my head against this too, as must everyone who isn't on the same DST as Germany. What I do is to manually set my time zone offset when DST goes into effect here, which works for a while until DST changes in Germany, after which I set my TZ offset again.

Which is silly.

 

[ingchr1]

Here's how I have mine set and it shows the correct time, I'm also on the east coast.

Here's what I do when the clocks change to get the time to change immediately, I do not use the "Change from winter to summer time" check box:

1. Set Automatic Setting to None (from NTP).
2. Set to PC-Time.
3. Set Time Zone. (Summer UTC-4, Winter UTC -5)
4. Save settings to controller.
5. Set Automatic Setting back to NTP.
6. Save settings to controller.

 

[Dave-T]

The point is - you shouldn't have to do anything. The Profilux should behave like every other internet connected device, it should automatically adjust the time. I guess there are scenarios where it should use the "days to process" thing, although I have no use for that in my application.

 

[BeanAnimal]

Here's how I have mine set and it shows the correct time, I'm also on the east coast.

Here's what I do when the clocks change to get the time to change immediately, I do not use the "Change from winter to summer time" check box:

1. Set Automatic Setting to None (from NTP).
2. Set to PC-Time.
3. Set Time Zone. (Summer UTC-4, Winter UTC -5)
4. Save settings to controller.
5. Set Automatic Setting back to NTP.
6. Save settings to controller.

That is insanity.... but the only apparent way to actually fix it twice a year I guess.

The point is - you shouldn't have to do anything. The Profilux should behave like every other internet connected device, it should automatically adjust the time. I guess there are scenarios where it should use the "days to process" thing, although I have no use for that in my application.

And considering that we can enter a longitude and latitude, a lookup table for offset should be trivial.

 

[BeanAnimal]

Insanely frustrating.

Last evening I turned off the use "winter to standard" time. Switched to "PC TIME" and synced. So the time was correct. I turned "NTP" back on and went to bed.

This morning I woke up and am back to the being an hour off. It is 10:10am NOT 9:10 AM.
This is the US Eastern Time Zone. We have been UTC-4 since the second Sunday in March. The EU switched the last Sunday in March (a week later than the US). It is now the first week if April. This is a dumpster fire. None of these settings make any sense. Combination of bugs and just bad implementation and documentation? Where are the answers?

We are currently UTC-4 - why is the clock an hour off from NTP? This is honestly ridiculous.

 

[BeanAnimal]

@Vinny@GHLUSA @Gaël

From November - same problem and no answers.

Timezone and DST

I know that timezones and DST can be frustrating to deal with.... And I know this has come up before, but I am frustrated with the way that P4 handles this. It is Nov 1 - I have a tinezone mismatch warning on my P4. It happens 2x a year and bothers the snot out of me. So it appears that it...

www.reef2reef.com

Overall this is a great product but there are issues here and there and you guys going silent after a "see the manual" is what angers the snot out of people.

This is not an isolated issue - we all have it and are all looking for an answer. It is not something that should be hidden behind a ticket for each of us to figure out on our own.

 

[BeanAnimal]

Being blatantly ignored is problematic here.

 

[KStatefan]

Being blatantly ignored is problematic here.

Examples like this is why I posted in another thread that GHL does not listen to their customers.

 

[BeanAnimal]

It is gatekeeping at its worst and honestly, rather insulting given what most of us have spent.

 

[NoWaiAma]

happy I found this thread. And sad. On to the apex. dangit

 

[Dave-T]

happy I found this thread. And sad. On to the apex. dangit

Huh?

 

[NoWaiAma]

Huh?

I was heavily leaning towards investing in GHL

 

[BeanAnimal]

I was heavily leaning towards investing in GHL

The hardware is mostly very good, better than the competitors IMHO.

 

[ingchr1]

happy I found this thread. And sad. On to the apex. dangit

I would take this minor software issue, that takes a couple of minutes a year to deal with, over the multiple hardware issues that the Apex powerbar and brain seem to have over time.

 

[NoWaiAma]

I would take this minor software issue, that takes a couple of minutes a year to deal with, over the multiple hardware issues that the Apex powerbar and brain seem to have over time.

I’m not sure why I typed apex. I like their bar and that’s it. As far as testing dosing I was thinking hydros. But every time I start looking I come back to the GHL.

I’d hate to buy right before they do a new release also not that it matters tbh