|
Please sign your posts with ~~~~
|
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision |
Your text |
| Line 20: |
Line 20: |
| | : For the crashing of the "recordkeeping system", as per title-text, this could be anything from deliberately "give a test we know crashes the (non-meta) system" by the testers to the non-tester recordkeepers not trusting the testers (and test-testers) and so trying to use the test-test data themselves upon a system of their own that is definitely not test-test-proof because they hadn't had asked for (test-)tester validation of it. (I've been part of a Change Control processing group where we've been made aware of a sub-group that has been reconfiguring its own little corner of the system without due reference to company policy, perhaps due to office politics and "it's nothing to do with them", etc.) | | : For the crashing of the "recordkeeping system", as per title-text, this could be anything from deliberately "give a test we know crashes the (non-meta) system" by the testers to the non-tester recordkeepers not trusting the testers (and test-testers) and so trying to use the test-test data themselves upon a system of their own that is definitely not test-test-proof because they hadn't had asked for (test-)tester validation of it. (I've been part of a Change Control processing group where we've been made aware of a sub-group that has been reconfiguring its own little corner of the system without due reference to company policy, perhaps due to office politics and "it's nothing to do with them", etc.) |
| | : But I'm not sure it's quite as simple as that. [[Special:Contributions/172.69.43.183|172.69.43.183]] 09:28, 7 May 2024 (UTC) | | : But I'm not sure it's quite as simple as that. [[Special:Contributions/172.69.43.183|172.69.43.183]] 09:28, 7 May 2024 (UTC) |
| − |
| |
| − | Changed away from the description of the javascript being "abused" by non-standard values. It may be a valid shortcut to just add a relevent ('over the top') value to <code>dayOfMonth</code> or <code>hourOfDay</code> variables, or even subtract and let the inbuilt algorithm resolve the oddness (with some testing, or documented confirmation, that it does the right thing).
| |
| − | <br/>If the core function isn't actually broken/fooled/exceptioned by out-of-normal-range inputs, it allows "this exact same time next week" without having to additionally do your own <code>this.day=this.day+7; if this.day>daysInMonth(this.month) { this.day=this.day-daysInMonth(this.month); this.month++; if this.month>valueDecember { this.month=valueJanuary; this.year++ } }</code> and hope you've not missed off any exception in your reinvention of the same wheel that the date-handling code has probably already covered. In ''at least'' as much detail as you just did, prior to feeding it with your 'presanitised' variables, but if you know you need to maybe add <code>,this.Year</code> to the <code>daysInMonth(...)</code> param, to cover leapyear differences then you already know to test the inbuilt function with an edge-condition to make sure ''it'' knows (before then looking to maybe fudge any adjusting code of your own to undo any inbuilt errors that you see).
| |
| − | <br/>And if it's already good enough to deal with everything necessary, with or without additional functionality-refinements, then it's just a bonus that you can actually supply a dateTime adjusted by subtracting some relevent <code>secondsInSiderealYear</code> from the current <code>observationTime.seconds</code> to give a different retrospective timestamp to if you had taken off <code>secondsInTropicalYear</code> instead (having tested that it does the right thing for your purposes when it leaps back from Gregorian into Julian calendars, if this is deemed relevent). Neater code, for which simple comments/documentation can reveal the pre-testing done that justifies it. You could even put that in validating initialiser that fails-over (or sets up an appropriate autocorrection flag) when it finds your script is being run with library versions of the functions (or within a set of ENV settings) that are wrong... Of course, it may take a bugrep from an end-user to ''know'' where it goes wrong, but if you're serious enough to reimplement the whole shebang manually with absolutely ''every'' possible issue of contention 'correctly' pre-handled, then you are also capable of saving yourself the effort and just validating whether the function calls were pre-pre-handling this already. You can be control-freaky in different ways (non-delegating or delegating-but-checking), much as you can let process errors slip through in different ways (significantly err yourself or miss significant errors already made by others).
| |
| − | <br/>Horses for courses, of course! [[Special:Contributions/172.70.90.172|172.70.90.172]] 13:59, 12 May 2024 (UTC)
| |
