Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl code that is syntactically correct only on Fridays

github.com

Post reply on HN
Print view View original

181–190 of 233 posts

Re: Perl code that is syntactically correct only on Fridays

#181

Post by Dylan16807 »

DocTomoe wrote: post #16
nicoburns wrote: post #14

Earlier quoted context omitted.

> I have written code that only works in winter because of daylight saving times and some unfortunate date conversions Not sure where you are located, but this can be particularly bad in the UK where winter time happens to coincide with UTC.

Let's be pedantic about this, because this is one of the very few areas where pedantry matters: GMT ("British Winter Time") is NOT UTC, and it can differ from UTC up to 0.9 seconds. GMT is a time zone (corresponding to UT1). UTC is a time standard.

> GMT is a time zone (corresponding to UT1)

Are you sure? Looking into things I would have said that GMT exists as a time reference but all the time zones are based on UTC.

Re: Perl code that is syntactically correct only on Fridays

#182

Post by VTimofeenko »

munk-a wrote: post #178
Spoom wrote: post #88

Earlier quoted context omitted.

Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?

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…

A great collection of those "every minute has 60 seconds" assumptions and why they are incorrect:

https://yourcalendricalfallacyis.com/

Re: Perl code that is syntactically correct only on Fridays

#183

Post by closeparen »

inquist wrote: post #64
knodi123 wrote: post #51

Earlier quoted context omitted.

Ha. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and t…

> an intern who wrote code .... his code had been in production You get what you pay for, eh?

Delivering real functionality in production (with code review from your mentor, of course) is absolutely standard at a Big Tech or hot startup internship.

Re: Perl code that is syntactically correct only on Fridays

#184

Post by jwilk »

reneberlin wrote: post #75

I don't get it! It is clearly written in the code, that the progam should behave this way. Is the proof, that perl is capable of this behaviour?! I don't get it - what is the point? I read all the comments and still don't get it. What am i missing?

It's a humorous way to demonstrate that you can't parse Perl code statically.

Re: Perl code that is syntactically correct only on Fridays

#185

Post by [deleted] »

skissane wrote: post #48
JohnDeHope wrote: post #19

Earlier quoted context omitted.

Right, the beauty of this is that it's a syntax error he's produced. Sure any language can write code to produce a runtime error under any condition at all. And a lot of languages have features that allow them to run code at compile time, and similarly produce errors then too. But those languages don't allow you to ruin the syntax of the language. I guess it's something that requires macros. Would it be safe to say t…

Common Lisp is another language in which this should be possible. Common Lisp allows you to run arbitrary code at compile-time, and that code is allowed to modify the language syntax (*READTABLE*, SET-MACRO-CHARACTER, etc). So code could make itself syntactically invalid on Fridays by changing the language syntax depending on the day of the week. This goes beyond mere Lisp macros, in that ordinary Lisp macro invocati…

[deleted]

Re: Perl code that is syntactically correct only on Fridays

#186

Post by jwilk »

high_pathetic wrote: post #140
iLoveOncall wrote: post #119

Earlier quoted context omitted.

What makes it "special" here is the fact that it will COMPILE only on a friday. It's not a runtime error but a compile time error. Because yes otherwise I would agree that it's doable easily in every single language.

Isn't perl an interpreted language? Or I am missing a point? What will happen when the command is `perl -c friday.pm`?

You get the same output with "perl -c". (Actually I've just updated README to use that.)

Note that the error message is "friday.pm had compilation errors, so yes, there's a compilation phase. It's not compiled to the machine code, though.

Re: Perl code that is syntactically correct only on Fridays

#187

Post by allenu »

alisonatwork wrote: post #26
johnnyo wrote: post #10

I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.

Fantastic. We had a similar problem with test code that always worked on a remote team's computers during their work day but failed when we got into the office and tried to run it in a different timezone.

I've seen something similar where some automated unit tests always passed and when I tried to run it locally would always fail. After digging around I realized it was making assumptions about the timezone it ran in, which was on the east coast, whereas I was on the west.

Re: Perl code that is syntactically correct only on Fridays

#190

Post by misnome »

dheera wrote: post #129
tentacleuno wrote: post #124

Earlier quoted context omitted.

> because how hard can it be to work with dates? Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.

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.

But I want my 4pm weekly meeting to always happen at 4pm, even if DST changes.
Post reply on HN