Hacker News Reader

Comment by polskibus | Hacker News Reader

Too bad, that will make it problematic to use for batch jobs that have to run at particular business hour.

What if your 'business hour' was 0130[^] (business logic for some reason, rather than a working hour, presumably; hence quotes) - what do you want to happen when you go in to Summer time, or come out of it? Does everybody want the same thing? Is it even obvious what it probably does such that nobody's going to have a bad night?

[^] in the UK at least, clocks go forward skipping the hour 0100-0200, and repeat it when they go back. If that happens at a different time where you are (this hypothetical feature gets even more complicated! and) then I mean whatever appropriate time for my point to make sense.

Not entirely sure why you're being downvoted, but it's true.

Sometimes you need something to run at 9am daily, in your local time zone. If your local time zone shifts for daylight savings, you can't define it in UTC without changing it twice a year.

Why? Can’t you just convert that business hour to UTC?

ho boy, before I break out "falsehoods programmers believe about time,"[0] nobody wants to manually have to rewrite the UTC time something's supposed to run at when the business hours keep changing relative to UTC for (at the most basic) Daylight Savings reasons.

[0] https://infiniteundo.com/post/25326999628/falsehoods-program...

(if this is your first time seeing this article, have fun! also check out the one about names.)

You don't have to do that "manually". Postgres supports the conversion using the `at time zone` operator.

This extension uses cron syntax and only supports GMT.

Reply on news.ycombinator.com