• Russell (unregistered)

    addHours(-1) I laughed out loud at that.

  • Russell (unregistered)

    Oh, and frist

  • Digicate (unregistered)

    I don't see any need to alter the hours.

    Plus I think you can use utcNow.format("Ymdh") ??

  • (cs) in reply to Russell
    Russell:
    addHours(-1) I laughed out loud at that.
    Well, there's nothing wrong with that - that's intended usage! http://msdn.microsoft.com/en-us/library/system.datetime.addhours(v=vs.110).aspx
  • moz (unregistered)

    Source control is optional? Sounds like the perfect opportunity for an misplaced "return true" to debug on Tuesday.

    Or they could check what files the cameras were actually producing.

  • Igor (unregistered)

    Doesn't the second version look for the file to be written at 11pm today the first hour after midnight?

  • moltonel (unregistered) in reply to Russell
    Russell:
    addHours(-1) I laughed out loud at that.

    To my non-java-trained eyes, this looks like a reasonable API call. A very ugly API for sure (who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?), but if you're going to implement an addhours() method, why forbid negative arguments ? You don't want to do the maths yourself, in order to handle DST correctly.

  • Balu (unregistered) in reply to moltonel
    moltonel:
    Russell:
    addHours(-1) I laughed out loud at that.

    To my non-java-trained eyes, this looks like a reasonable API call.

    Well, it's C#, isn't it? And the equivalent to Date("now-1h") in C# is DateTime.Now.AddHours(-1);
  • nak (unregistered)

    DateTime.Now.ToFileTimeUtc() surely?

  • (cs) in reply to moltonel
    moltonel:
    Russell:
    addHours(-1) I laughed out loud at that.

    To my non-java-trained eyes, this looks like a reasonable API call. A very ugly API for sure (who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?), but if you're going to implement an addhours() method, why forbid negative arguments ? You don't want to do the maths yourself, in order to handle DST correctly.

    there is no DST in UTC

    also a format call would be infinitely better than that horrendous setup

  • Kelerei (unregistered) in reply to ratchet freak

    This should do it:

    string fileName = Path.Combine(videoPath, String.Format("{0:yyyyMMddHH}.{1}", utcNow.AddHours(-1D), ConfigurationManager.AppSettings["VideosExtension"]));
  • Geoff (unregistered) in reply to Digicate
    Digicate:
    I don't see any need to alter the hours.

    Plus I think you can use utcNow.format("Ymdh") ??

    My guess would be he needs to check for the archive file after its closed, the camera software probably closes and renames its archive files every hour or something. So if he runs at 23:00 he probably needs to be looking for a file named for the 22:00 hour. Otherwise it might be a full hour before the monitor discovers the video camera's have failed.

    The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

  • Datetimes in filenames are fine. (unregistered) in reply to Geoff
    Geoff:
    The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime. Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools. If you are really really worried about losing the filesystem metadata somehow, then just append the files name and data to CSV file or database somewhere at create time.

    Why exactly is that an anti-pattern, and not just your opinion on the matter?

    There is no technical reason why filenames should not contain datetime info, assuming you use a format which allows alphanumeric sorting.

    In addition, if you have a file of "video footage for the security camera in the lobby between 6 and 7 today" then the location of the footage and the datetime it was taken are the actual contents of the file... in this case the datetime isn't meta-data, it's integral to accurately describe the content of the file, and is therefore appropriate to include that info in the title of the file.

    To not include such data is to produce a bunch of inconveniently named files, just so that you can feel smug about sticking to some weird (and spurious) file naming principle.

  • doug (unregistered)

    nothing to do with the story, but why does the first page of comments have a "prev" in the lower left? it is not linked to anything.

  • faoileag (unregistered) in reply to Geoff
    Geoff:
    The TWTF is the anti-pattern of naming files with dates. The filesystem already keeps track of cdate, mdate, and often atime.
    Is it possible you haven't used the explorer on a windows system in the last couple of years or so?

    Standard behaviour out of the box is some sort of gallery view - a nice thumbnail, name underneath.

    cdate, mdate, atime? Available, you just have to right click on the file and select "Properties", after which a nice window opens up (which you will then have to close again).

    Care to do that for the 168 files the cover the last seven days of a camera? Thought so.

    A filename should be descriptive and the YYYYMMDDHH pattern is descriptive.

    Yes, you can set windows explorer to "list view" modus. But if you look closely, what is displayed is the mdate, not the cdate. Any change to the file and you are lost.

    Geoff:
    better just to give the files consecutive numbers
    And you gain what exactly against the YYYYMMDDHH? Nothing.

    Apart from the fact that for each generated file you have to find out the highest filenumber used, and then increment that by 1.

    Oh, and what if you move all the files from the avi directory to an archive folder on some other drive? How will you then determine the next filename? If you start with 1.avi again, you will get ambiguous file names.

    There are two reasons why the YYYYMMDDHH pattern is in widespread use: first, if you stick to the pattern, the filenames are unique for all eternity (well, at least until the year 9999). Second, YYYYMMDDHH is a number. A number that makes comparisons rather easy. If all you ever need is "is a greater/less than b" YYYYMMDDHH is for you.

    You were advocating numbers for the filenames. Well, that's what you've got with the pattern.

  • (cs) in reply to Geoff
    Geoff:
    The filesystem already keeps track of cdate, mdate, and often atime.

    So you';ve got a bunch of cameras each dumping 1hrs worth of captured video to a storage subsystem, and you want to trust the filesystem as a reliable moderator of what information that file contains?

    Sure, that sounds robust to me.

    (and while we're here, I'm pretty sure TRWTF is that you can't spell TRWTF...)

  • Neil (unregistered) in reply to doug
    doug:
    nothing to do with the story, but why does the first page of comments have a "prev" in the lower left? it is not linked to anything.
    It's the semantic equivalent of a disabled control.
  • Spencer (unregistered)

    utcNow.AddHours(-1) is correct. However he should be subtracting one from the whole date object, and formatting the output from that.

    Subtracting one from the hour at midnight will result in the 23rd hour from the previous day, but since he is only ripping out the HH part the whole date rollover gets lost.

  • (cs) in reply to JimM
    JimM:
    (and while we're here, I'm pretty sure TRWTF is that you can't spell TRWTF...)
    Actually, we don't know that. He might have *meant* that it was only *The* WTF, and not The *Real* WTF.

    But that's pretty lame in its own right...

    (But not as lame as the stuff on The Lame List.)

  • moltonel (unregistered) in reply to ratchet freak
    ratchet freak:
    moltonel:
    To my non-java-trained eyes, this looks like a reasonable API call. A very ugly API for sure (who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?), but if you're going to implement an addhours() method, why forbid negative arguments ? You don't want to do the maths yourself, in order to handle DST correctly.

    there is no DST in UTC

    also a format call would be infinitely better than that horrendous setup

    Fair enough, I don't know much java nor c# (and don't mind keeping it that way).

    So... I still don't see where the bug is. I'd have implemented things differently for sure, but how does that code fail ?

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    Actually, we don't know that. He might have *meant* that it was only *The* WTF, and not The *Real* WTF.

    But what he wrote was "The TWTF". So ... the True WTF perhaps? Do we have a believer in our midst?

    The THE WTF? It's so definite it needs two definite articles?

    Any other options? ;)

  • (cs) in reply to moltonel
    moltonel:
    ... I still don't see where the bug is. ... how does that code fail ?

    If it actually subtracted 1 hour from the date it'd be fine.

    But what it does is get the current year, month, and hour separately, then concatenate them. So instead of looking for, say, 2014020323.avi, it looks for 20140204-01.avi.

    EDIT: sorry, should add - the second version would produce 2014020423.avi for the above example. Closer, but still wrong ;)

  • (cs) in reply to moltonel
    moltonel:
    ratchet freak:
    moltonel:
    To my non-java-trained eyes, this looks like a reasonable API call. A very ugly API for sure (who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?), but if you're going to implement an addhours() method, why forbid negative arguments ? You don't want to do the maths yourself, in order to handle DST correctly.

    there is no DST in UTC

    also a format call would be infinitely better than that horrendous setup

    Fair enough, I don't know much java nor c# (and don't mind keeping it that way).

    So... I still don't see where the bug is. I'd have implemented things differently for sure, but how does that code fail ?

    there is no handling for hour roll-over -> 0 becomes 23 on the same day instead of the previous day

  • Walky_one (unregistered) in reply to Geoff
    Geoff:
    Seriously in a situation like better just to give the files consecutive numbers not only do you avoid these types a problems; you get filenames that will always sort neatly with other tools.

    Well... I give you:

    Video_98 Video_99 Video_100 Video_101

    (and if you tell me "You just have to prefix the zeroes of course". The I tell you "As soon as you tell me the maximum number of digigs... Of Course")

    In short: IF you're doing time specific stuff YYYYMMDDHH is way better!

  • faoileag (unregistered) in reply to Spencer
    Spencer:
    utcNow.AddHours(-1) is correct
    No, even if Ted had applied the AddHours(-1) to utcNow before starting to build the filename, it is not.

    It will always look for the files generated one hour removed.

    Say the cameras save on the full hour, and that the camera is disabled on February 3rd, somewhere between 22:00 and 22:59. Say, at 22:10.

    On February 3rd at 23:05 the monitor will test for 2014020322.avi and will find it.

    On February 4th at 00:05 the monitor will test for 2014020323.avi and will not find it. An alarm goes of.

    The point is, the alarm is going off one hour late. For security systems, such an error can be close to unacceptable.

  • faoileag (unregistered) in reply to moltonel
    moltonel:
    ratchet freak:
    moltonel:
    To my non-java-trained eyes, this looks like a reasonable API call. A very ugly API for sure (who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?), but if you're going to implement an addhours() method, why forbid negative arguments ? You don't want to do the maths yourself, in order to handle DST correctly.

    there is no DST in UTC

    also a format call would be infinitely better than that horrendous setup

    Fair enough, I don't know much java nor c# (and don't mind keeping it that way).

    So... I still don't see where the bug is. I'd have implemented things differently for sure, but how does that code fail ?

    The code fails because the filenames generated by the monitor (written by Ted) and the filenames generated by the cameras differ at midnight.

    Camera: 2014020300.avi Ted: 20140203-1.avi

    The file 20140203-1.avi does not exist, so the monitor assumes camera malfunction and falsely raises an alarm.

  • Franky (unregistered)

    lol, saw exactly the same problem in one of our (ops-developed) server management tools (though nothing critical, just prefilling some date)

    DateTime.Now.addHours(-[2]).Hour DateTime.Now.Day DateTime.Now.Month DateTime.Now.Year

    close, but no cigar ;) on the other hand, that thing is only supposed to be on test anyway and nobody is testing stuff at 22:00 anyway.

  • QJo (unregistered) in reply to JimM
    JimM:
    Steve The Cynic:
    Actually, we don't know that. He might have *meant* that it was only *The* WTF, and not The *Real* WTF.

    But what he wrote was "The TWTF". So ... the True WTF perhaps? Do we have a believer in our midst?

    The THE WTF? It's so definite it needs two definite articles?

    Any other options? ;)

    The technical WTF? As opposed to the management WTF or the inappropriate-personal-behaviour WTF?

  • nobulate (unregistered)

    The right way (TM) is to create a look-up table of pre-calculated file names:

        ID            FILENAME
    ------------------------------
    -1            FILE_NOT_FOUND
    1391528420    \2013123123.mpeg
    1391532020    \2014010100.mpeg

    Because then you can store the ID as the seconds since the last epoch as the lookup key! Zing!

    SELECT FILENAME WHERE ID = DATEDIFF(s,'19700101', getdate())
  • QJo (unregistered)

    TRWTF is Eric a) not using Ted's cellphone and b) not using the elevator. Although, to be fair, it doesn't state on which floor the programming is being done -- if it's floor 14 then Eric's feat of athleticism is possibly borderline excusable.

  • saveddijon (unregistered)

    I'm not sure what language this is, but if utcNow is a function call, and not just a variable, then you have a race condition: if part of the expression executes a microsecond before midnight, and part a microsecond after, then you could be up to a YEAR off, even without needing to subtract that hour.

  • Bill P. Godfrey (unregistered)

    If this story takes place at midnight in New York, isn't UtcNow going to return a timestamp around 5am?

    Unless they mean New York, England. http://en.wikipedia.org/wiki/New_York,_Tyne_and_Wear

  • foo AKA fooo (unregistered) in reply to Bill P. Godfrey
    Bill P. Godfrey:
    If this story takes place at midnight in New York, isn't UtcNow going to return a timestamp around 5am?

    Unless they mean New York, England. http://en.wikipedia.org/wiki/New_York,_Tyne_and_Wear

    New Year != New York (even though both match /^New Y...$/).

  • faoileag (unregistered) in reply to nobulate
    nobulate:
    The right way (TM) is to create a look-up table of pre-calculated file names:
    Is it possible that you took this as inspiration?
    nobulate:
    Because *then* you can store the ID as the seconds since the last epoch as the lookup key!
    I see how this comes in handy. You convert a timestamp (now) into seconds since epoch start, an operation for which C#'s DateTime offers no direct property or method, then query a database to get a filename that you could as well have assembled with utcNow.ToString('YYYYMMDDHH') + '.avi'.

    But still not enterprisey enough. Where's the xml and the regex?

  • Bill P. Godfrey (unregistered) in reply to foo AKA fooo
    foo AKA fooo:
    Bill P. Godfrey:
    If this story takes place at midnight in New York, isn't UtcNow going to return a timestamp around 5am?

    Unless they mean New York, England. http://en.wikipedia.org/wiki/New_York,_Tyne_and_Wear

    New Year != New York (even though both match /^New Y...$/).

    Oops....

    Ummmm....

    I did say "if this story takes place in New York."

  • (cs) in reply to faoileag
    faoileag:
    The code fails because the filenames generated by the monitor (written by Ted) and the filenames generated by the cameras differ at midnight.

    Camera: 2014020300.avi Ted: 20140203-1.avi

    The file 20140203-1.avi does not exist, so the monitor assumes camera malfunction and falsely raises an alarm.

    If Ted gets that, the camera should be 2014020223.avi

    QJo:
    TRWTF is Eric a) not using Ted's cellphone and b) not using the elevator. Although, to be fair, it doesn't state on which floor the programming is being done -- if it's floor 14 then Eric's feat of athleticism is possibly borderline excusable.
    I have a very strong suspicion that the stuff about the party was invented as part of the TDWTFification, solely to get a cigar into the story. If I'm wrong then TRWTF is deploying a project on New Year's Eve.
  • homsar (unregistered) in reply to Bill P. Godfrey
    Bill P. Godfrey:
    foo AKA fooo:
    Bill P. Godfrey:
    If this story takes place at midnight in New York, isn't UtcNow going to return a timestamp around 5am?

    Unless they mean New York, England. http://en.wikipedia.org/wiki/New_York,_Tyne_and_Wear

    New Year != New York (even though both match /^New Y...$/).

    Oops....

    Ummmm....

    I did say "if this story takes place in New York."

    The story says the that "the ball had just dropped"; I don't know where in the world balls drop for New Year outside of New York, New York. (Not aware of any dropping at midnight in anywhere that has a time zone aligning with UTC at New Year.)

  • (cs) in reply to JimM
    JimM:
    Steve The Cynic:
    Actually, we don't know that. He might have *meant* that it was only *The* WTF, and not The *Real* WTF.

    But what he wrote was "The TWTF". So ... the True WTF perhaps? Do we have a believer in our midst?

    The THE WTF? It's so definite it needs two definite articles?

    Any other options? ;)

    Bah. I should read more carefully. Bah.

    I suppose it might be the Teleological WTF. (WTF By Design?)

  • foo AKA fooo (unregistered)
    "Close," he said, plucking the Macanudo from Ted's shirt pocket and putting it in his own. "But no cigar."
    What a nice way to dramatize this proverb. And so subtle! What can we look forward to?

    • The GlassHouse application throwing an exception of type EStone.

    • ... which fails because EarlyBird() only catches EWorm.

    • Forgetting to free() the Lunch pointer.

    • Closing the Friends file without closing the Enemies file first.

    • Misusing the /home directory.

  • faoileag (unregistered) in reply to pjt33
    pjt33:
    faoileag:
    The code fails because the filenames generated by the monitor (written by Ted) and the filenames generated by the cameras differ at midnight.

    Camera: 2014020300.avi Ted: 20140203-1.avi

    The file 20140203-1.avi does not exist, so the monitor assumes camera malfunction and falsely raises an alarm.

    If Ted gets that, the camera should be 2014020223.avi
    That's the problem with Ted's "fix" of AddHour(-1): it is just as broken:

    Camera: 2014020300.avi Ted (fixed): 2014020323.avi

    2014020323.avi does (not yet) exist, so again Ted's monitor raises a false alarm.

    pjt33:
    I have a very strong suspicion that the stuff about the party was invented as part of the TDWTFification
    Agreed. But it's ok since it supports the wtf in a nice way (quick buggy hack, bugfix buggy as well). You can excuse Ted for not thinking too clearly during a party; without the party, Ted's fix would represent a nice head->desk moment.
  • neminem (unregistered)

    Heh, I found something like that in some internal code I inherited a while back - only it was in a filter on the Month, so nobody had noticed it until December: take the current month, turn it into an int, add one, turn it back into a month. Brillant.

  • faoileag (unregistered) in reply to neminem
    neminem:
    nobody had noticed it until December: take the current month, turn it into an int, add one, turn it back into a month.
    Did that give you the "undecember"?
  • (cs) in reply to moltonel
    moltonel:
    Russell:
    addHours(-1) I laughed out loud at that.

    To my non-java-trained eyes, this looks like a reasonable API call. A very ugly API for sure (who wouldn't prefer Date("now -1h").format("YYYYMMDDHH") ?), but if you're going to implement an addhours() method, why forbid negative arguments ? You don't want to do the maths yourself, in order to handle DST correctly.

    I hate those "language inside a language" types of APIs. The meaning of "utcNow.Hour.AddHour(-1)" is pretty freaking obvious[1] and easy to remember.

    With "Date('now -1h'), you have a new language that you need to learn. It may be a simple language, but it's still new, and it opens up new possibilities for parsing bugs or surprising behavior (does "now -1:30" work?). Plus that language isn't type checked or even compiled. If it's bombs, it does so at run time. If you – god forbid – mix user-supplied data into that format string, does it open up new new security vulnerabilities?

    Keep it simple, stupid.

    1. The one caveat is the one under discussion in this thread: it's unclear if it handles underflow correctly. Given that most date APIs do, I would expect the same here. And this same ambiguity applies to "language inside a language" example, too.
  • Erik Thorvaldsson (unregistered)

    UTC-1? Seriously?!

  • caffeine (unregistered)

    My good friend Rory Jack Thompson once told me always manipulate your date before chopping into pieces...

    We had different interpretations of course but still sage advice...

  • Not Santa (unregistered) in reply to JimM
    JimM:
    Steve The Cynic:
    Actually, we don't know that. He might have *meant* that it was only *The* WTF, and not The *Real* WTF.

    But what he wrote was "The TWTF". So ... the True WTF perhaps? Do we have a believer in our midst?

    The THE WTF? It's so definite it needs two definite articles?

    Any other options? ;)

    Obviously it's "The TIME WTF", duh

  • Jeremy (unregistered) in reply to Geoff
    Geoff:
    Digicate:
    I don't see any need to alter the hours.

    Plus I think you can use utcNow.format("Ymdh") ??

    My guess would be he needs to check for the archive file after its closed, the camera software probably closes and renames its archive files every hour or something. So if he runs at 23:00 he probably needs to be looking for a file named for the 22:00 hour. Otherwise it might be a full hour before the monitor discovers the video camera's have failed.

    I'm thinking the answer is simper than that. If you're saving a file at 11pm it's the video from 10pm to 11pm (or 10:59:59). Granted they could just remember that the 2014020323 file is in fact for 22-23, but it makes slightly more sense to name it with the start time.

  • Jakob (unregistered)

    "Whatever you do, don't feed it after midnight" I've heard that before somewhere...

  • (cs) in reply to faoileag
    faoileag:
    ... It will always look for the files generated one hour removed. ...

    ... On February 3rd at 23:05 the monitor will test for 2014020322.avi and will find it. ...

    You're assuming the hour in the filename is the save time of the recording. If it's the start time of the recording, the -1 logic is correct i.e. 2014020322.avi is the file that starts at 22:00 on 03/02/2014*

    *waits for inevitable argument about endianism of dates...

  • (cs)

    Just posting to troll that TRWTF is our insane set of units for time - years, days, hours, .. all those nondecimal (or non hexadecimal, alla same) units.

    Or maybe TRRWTF is that our planet refuses to complete a revolution in an integral number of solar-oriented rotations.

Leave a comment on “The Midnight Cowboy Coder”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article