Perl code that is syntactically correct only on Fridays • Hacker News Board

Re: Perl code that is syntactically correct only on Fridays

#211

Post by notreallyserio » Thu, Feb 17, 2022, 5:18 AM UTC

mypalmike wrote: post #160

dheera wrote: post #129

Earlier quoted context omitted.

Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.

That's a good starting point, and certainly good advice for marking current time and past times. But keep in mind that future event absolute UTC can change due to politics, e.g. a change in daylight savings rules, which is less rare than you might imagine ( https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun... ). That concert scheduled a year from now at 8pm in UTC+5 might actually end up occurring at 8pm i…

> certainly good advice for marking current time and past times

But not too far past!

Re: Perl code that is syntactically correct only on Fridays

#212

Post by ihateolives » Thu, Feb 17, 2022, 5:56 AM UTC

cstejerean wrote: post #205

markstos wrote: post #62

Earlier quoted context omitted.

We had situation where if you worked late, the test suite would consistently fail. Since developers rarely worked late and would give up when hitting the "random" test suite failure and go home, the bug persisted for months before the true cause was understood. Our time zone was UTC-5, and the test suite contained a local-vs-UTC bug which only triggered between 7pm and midnight.

I had to fix tests that broke from 11pm-midnight because some assumptions that now() + 1 hour was the same local date.

I worked with date range in a service that expected start date to be inclusive, but end date to be exclusive. So when you wanted to get data from dates 12-15, you'd have to send query for 12-16.

Re: Perl code that is syntactically correct only on Fridays

#213

Post by ihateolives » Thu, Feb 17, 2022, 7:08 AM UTC

mark-r wrote: post #131

ihateolives wrote: post #47

Earlier quoted context omitted.

I once had to implement date picker that returned the date to be sent to backend to fetch the day's reservations. It seemed to work fine the day I implemented it. Next day it broke. Turned out the widget returned MM/DD/YYYY instead of DD/MM/YYYY. And I implemented it on 10th of October.

I'm a big fan of ISO 8601. Eliminates the confusion, and sorts lexicographically too.

Yeah, me too. I had severe time constraints (heh) and just wanted to be done with it with minimal conversion. Which I then had to do anyway later. I also learned on that day that Javascript's getUTCMonth() is zero-based (January is month 0). And I had to sync time between timezones as well. I don't want to work with dates ever again.

Re: Perl code that is syntactically correct only on Fridays

#214

Post by randomswede » Thu, Feb 17, 2022, 7:47 AM UTC

Dylan16807 wrote: post #180

tristor wrote: post #155

Earlier quoted context omitted.

> he figured time syncing wasn't important enough to justify a daemon Time synchronization is very arguable THE most important thing on a server (for numerous security related reasons). How many moons ago was this incident? It's perhaps forgivable ignorance in the 90s... not so much today.

For security? Kerberos usually has a 5 minute tolerance. Are you saying that's wrong? Because if your hardware/firmware isn't literally broken you won't drift anywhere near that in a day. NTP can't properly fix a clock like that either since it's often capped at adjusting the speed by one part per two thousand. At most, with a consistently wrong clock, that can handle about 30 seconds per day. Any worse than that and…

The bigger the clock skew, the harder it is to correlate events from logs. The harder it is to corelate, the more information needs to come from your machine-fueled winnowing stage, to the final inspection by eyeballs.

1-2 seconds is (probably) well within manageable. But, since you now know for SUER that you have clocks running at different speeds, you need to over-estimate the skew. And hope that the daily skewing is approximately constant over time.

So, yes, clock skew can have an impact on your security, because it makes event correlation (and followup on security incidents) harder.

Re: Perl code that is syntactically correct only on Fridays

#215

Post by Dylan16807 » Thu, Feb 17, 2022, 7:53 AM UTC

randomswede wrote: post #214

Dylan16807 wrote: post #180

Earlier quoted context omitted.

For security? Kerberos usually has a 5 minute tolerance. Are you saying that's wrong? Because if your hardware/firmware isn't literally broken you won't drift anywhere near that in a day. NTP can't properly fix a clock like that either since it's often capped at adjusting the speed by one part per two thousand. At most, with a consistently wrong clock, that can handle about 30 seconds per day. Any worse than that and…

The bigger the clock skew, the harder it is to correlate events from logs. The harder it is to corelate, the more information needs to come from your machine-fueled winnowing stage, to the final inspection by eyeballs. 1-2 seconds is (probably) well within manageable. But, since you now know for SUER that you have clocks running at different speeds, you need to over-estimate the skew. And hope that the daily skewing…

"It makes logs more annoying, and sometimes security needs logs" is a pretty weak connection, though. And it's a far cry from precise timing being "THE most important thing on a server". Is there anything more direct at all?

Re: Perl code that is syntactically correct only on Fridays

#216

Post by withinboredom » Thu, Feb 17, 2022, 9:46 AM UTC

hwc wrote: post #198

munk-a wrote: post #178

Earlier quoted context omitted.

There are seven time zones in Indiana in the tz database[1] - this doesn't count the two most used ones America/Chicago and America/New_York there's also a Kentucky tz that slightly spills into the state. Whenever anyone makes any comment about dates and times being easy to compute I just mention that yes, there are seven time zones in Indiana . Now the actual issues tend to arise when software makes assumptions like…

I just want to specify International Atomic Time, relative to some universally-agreed-upon epoch, in nanosecond units.

So without leap seconds/days, how does one keep their clocks in sync with reality?

Re: Perl code that is syntactically correct only on Fridays

#217

Post by sundarurfriend » Thu, Feb 17, 2022, 10:00 AM UTC

hnick wrote: post #201

WesolyKubeczek wrote: post #41

Earlier quoted context omitted.

Good Perl code would also look pretty boring, almost like enterprise Java. I'd wager that all code that "just works", in any language, looks bland and predictable. But I'd rather have that than cute and clever any day.

You say that but a lot of people just can't get over the sigils.

And a lot of people just can't get over significant whitespace, and curly braces, and lispy parantheses, and semicolons. No syntax can please everyone, especially so with people unfamiliar with the language they're looking at.

Re: Perl code that is syntactically correct only on Fridays

#218

Post by jwilk » Thu, Feb 17, 2022, 10:48 AM UTC

justintoon wrote: post #189

Am I literally the only person who sees the pun against “His Girl Friday?” Maybe it wasn’t intentional but that’s literally the first thing I thought of.

It wasn't intentional. Can you explain the pun?

Re: Perl code that is syntactically correct only on Fridays

#219

Post by tremon » Thu, Feb 17, 2022, 11:56 AM UTC

knodi123 wrote: post #103

darkwater wrote: post #98

Earlier quoted context omitted.

A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.

Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)

after all, how far can clocks drift in a single day!?

Well, having run a Linux kernel on OpenBSD's vmm: they can drift more than a single day in that time. I did have to resort to using an ntpdate cron job because ntpd just couldn't cope with the time dilation effect. The cron job was configured at * * * * * (i.e. every minute), which roughly translated to once every 180 wall-clock seconds (+/- 30s).

Re: Perl code that is syntactically correct only on Fridays

#220

Post by tremon » Thu, Feb 17, 2022, 12:07 PM UTC

ihateolives wrote: post #212

cstejerean wrote: post #205

Earlier quoted context omitted.

I had to fix tests that broke from 11pm-midnight because some assumptions that now() + 1 hour was the same local date.

I worked with date range in a service that expected start date to be inclusive, but end date to be exclusive. So when you wanted to get data from dates 12-15, you'd have to send query for 12-16.

That sounds like a naive date->datetime conversion rather than explicit boundary exclusion. If you convert a date to a datetime, you get midnight at the start of day, which is fine if you're only comparing dates, but fails spectacularly in the way you describe for date ranges.

MSSQL not supporting a DATE data type has been the bane of my existence for a long time (of course, Postgresql has supported it since forever, but try telling your application vendor that). And since it took so long to include it, hardly any application uses it even today, because of inertia and compatibility with existing databases.