View Topic

I get it. Usually, popular programming languages have standardized functions to deal with stuff like DST or obtaining epoch timestamps, manipulating them and converting them back to readable human time and so on. I know that's pretty easily done in Java.

I'm an industrial controls guy and our platforms usually aren't so full featured. On North America's most used platform, you have to sync the controller to a time server or roll your own calendar math to adjust for DST because it doesn't do it on its own. On most of my clients' OT networks, a workable "time server" is not available, so roll the calendar math it is. You've gotta check for the first Sunday on March and November and flip the time then. You don't get a day of week integer from the controller so you have to calculate it from the given date.

Another fun time problem I've had to wrestle with recently was how to get the right best before date into a controller from an SQL server that stored the product's shelf life in number of days. The timestamp I could get from the controller was an array of two 32-bit integers representing milliseconds since Unix, because of course that platform semi-handles 64-bit types on the latest firmware (it'll do basic arithmetic but that's it), but did not at all on my client's firmware (and upgrading is a can of worms I'm not gonna get into in this post). Instead of dealing with that, I did calendar math to get the Julian day, added the shelf life to that day and reconverted it to a date.

At least the stupid calendar math has mostly already been done for us but you've gotta know it exists and actually can be done. Incidentally, I later got a sister plant's solution to the problem and it involved nearly a thousand lines of code doing logical comparisons.

From a purely selfish perspective, scripting and programming software and having to worry about time zones is hard enough, especially cause of situations where some time zones aren't full one hour differences but 30 minute differences (at least pretty sure there are a couple like this).

Throw in having to deal with DST and then throw in states in the US that don't follow it at all anyways and then dealing with other countries where they implement DST at different times than other countries is also difficult enough. Then you have some instances where a city or town chooses not to follow DST at all even though their country does! But everyone always wants their app to show the right time, it's tough!

So I'd rather just see the shifting between DST and not DST to just be done away with completely. But again, this is just a purely selfish perspective...

I like how the forums here deal with it...just leave it up to the user to constantly have to update their time offset

I haven't looked, and it wouldn't apply to @Seroim's situation (who seems to have come up with his own excellent solution anyways), but I'm surprised there aren't APIs that tracks time zones and DST automatically.

From a purely selfish perspective, scripting and programming software and having to worry about time zones is hard enough, especially cause of situations where some time zones aren't full one hour differences but 30 minute differences (at least pretty sure there are a couple like this).

Throw in having to deal with DST and then throw in states in the US that don't follow it at all anyways and then dealing with other countries where they implement DST at different times than other countries is also difficult enough. Then you have some instances where a city or town chooses not to follow DST at all even though their country does! But everyone always wants their app to show the right time, it's tough!

So I'd rather just see the shifting between DST and not DST to just be done away with completely. But again, this is just a purely selfish perspective...

I like how the forums here deal with it...just leave it up to the user to constantly have to update their time offset

I haven't looked, and it wouldn't apply to @Seroim's situation (who seems to have come up with his own excellent solution anyways), but I'm surprised there aren't APIs that tracks time zones and DST automatically.

I get it. Usually, popular programming languages have standardized functions to deal with stuff like DST or obtaining epoch timestamps, manipulating them and converting them back to readable human time and so on. I know that's pretty easily done in Java.

I'm an industrial controls guy and our platforms usually aren't so full featured. On North America's most used platform, you have to sync the controller to a time server or roll your own calendar math to adjust for DST because it doesn't do it on its own. On most of my clients' OT networks, a workable "time server" is not available, so roll the calendar math it is. You've gotta check for the first Sunday on March and November and flip the time then. You don't get a day of week integer from the controller so you have to calculate it from the given date.

Another fun time problem I've had to wrestle with recently was how to get the right best before date into a controller from an SQL server that stored the product's shelf life in number of days. The timestamp I could get from the controller was an array of two 32-bit integers representing milliseconds since Unix, because of course that platform semi-handles 64-bit types on the latest firmware (it'll do basic arithmetic but that's it), but did not at all on my client's firmware (and upgrading is a can of worms I'm not gonna get into in this post). Instead of dealing with that, I did calendar math to get the Julian day, added the shelf life to that day and reconverted it to a date.

At least the stupid calendar math has mostly already been done for us but you've gotta know it exists and actually can be done. Incidentally, I later got a sister plant's solution to the problem and it involved nearly a thousand lines of code doing logical comparisons.

Both of you are very true here in that, most programming languages have plenty of ways of countering this whether that be through built-in functions/methods or by importing libraries as addons that help counter this (I mostly work in PHP, Python, BASH, and Powershell). The problem isn't necessarily doing the conversion and getting it set up, as if I (as the programmer) am the one inputting the data or just pulling the time from a machine or event, then it can be countered pretty easily.

The problem that I am encountering currently (which is probably what I should've led with so my apologies for being vague!) is relying on user submitted data, then storing that in a way that retains the originality of what the user submitted, while also ensuring the accuracy of what is returned to the user when they ask for it later haha. All in all, still definite ways of dealing with it, but man is it still a pain!