Value of Null?
BlitzMax Forums/BlitzMax Beginners Area/Value of Null?
| ||
| Maybe a dumb question but I was always under the impress that Null had no value? e.g. mynumber:int = Null Would be the same as... mynumber:int = which would obviously give an error. However, I've been trying to use Null as a default value in a Method but BM then takes Null as being equal to 0 The method I have uses three parameters used to for the date , i.e. DD, MM, YYYY If these value are omitted when calling the Method I want to then get these values from the systemdate (CurrentDate$).... Mymethod (DD=Null, MM=Null, YYYY=Null) <code here> end method is the same as doing... Mymethod (DD=0, MM=0, YYYY=0) <code here> end method Which is not very useful because the year foir example could be valid as 0000. Any ideas? The only thing I can think of is providing some obscure default values, like -567? Cheers. :) |
| ||
| Ahm, I don't quite understand what you're trying to say, but: In general you use NULL only for telling the garbage collector that a certain variable can be cleared from memory. In all other cases like doing math always set a var=0. Simple as that. And I had no difficulties with it so far. |
| ||
| To expand on that, you should use null to refer to an object that doesn't have an instance of a type attached to it. Like if you had an array of MyType, until you create the instances of MyType for each array element they are all Null, which means `end of the road, don't go any further looking for data`. And yes Null has the value 0 when used for math purposes. |
| ||
| I thought C++ was migrating towards null = 0 for all things? |
| ||
| This also reminds me of an issue with function pointers. Well, not an issue so much. If you set a function pointer to Null, it doesn't become 0, it becomes the pointer to the Null() function. And because the Null() function is at some arbitrary address in memory, the function pointer actually holds a nonzero value which is the address of the Null() function. So if you test the value of a function pointer, you should test for Null, not for 0. |
| ||
| This is what the docs have to say about Null... Null returns 0, an empty string, an empty array, the null object or a pointer to 0 depending on context. |
| ||
| Well it would seem quite conclusively that I won't be able to do as I hoped as used Null as my default setting. Anyone got any suggestions as to an alternative other than using an obscure number as a default and hope the user's program never uses it? |
| ||
| Is there a reason you need them as Ints? Could you set them as strings to default "DD", "MM", "YY" and, if you need to do any calculations, convert to int and then back again? |
| ||
| Ok do the year NULL has a sensible value 0000, but it would still be the 0th of the 0th 0000, which is not valid. And (I believe) that if you had a type date, with fields of day, month and year, that the year is not 0000, because the type would be NULL, and not the fields. |
| ||
| Fortunately there is no year zero in the Gregorian calendar: it goes directly from 1 BC (-1) to 1 AD. So YYYY = 0 is a fine candidate for "use CurrentDate()." But as for the issue itself, where 0 is a valid parameter along with positive integers, -1 is sometimes used to specify that the default approach should be used. Where the full range of -number to +number is permitted, including 0, using strings as suggested by tonyg makes sense, like: Function blah$( a$ = Null ) If a = Null Then Return "none" Else Return String( Int(a) * 2 ) EndIf End Function Print blah() ' returns "none" Print blah(0)' returns "0" Print blah(3)' returns "6" |
| ||
| I suppose I should explain a bit more about what my program or rather code is going to be for, hopefully this will make for a little more sense... Basically, I'm making a type that I hope eventually to turn into a Module with the intention of it being a little more useful than just CurrentDate$ with regards to dealing with dates. Each method within the type is normally going to be called with the parameters of DD, MM and YYYY as integers. It has been my intention all along to use integers rather than strings for the date for the sake of making the module a little more intuitive to use plus I wanted to use the values as values rather than strings - if that makes sense? For most of these methods I want to get the DD, MM and YYYY parameters from CurrentDate$ if they have not been provided. On the whole the project is working out quite well and I'm hoping by the end of it I'll have a nice straight forward Module for public release - kinda a learning curve for me getting into BM, plus I'd like to give something back to the community from which I'm getting help from. :) WendellM Thanks for that, I did not realise that the Gregorian calender started at the year 0001, this should make using 0 as the default for all three parameters possible, i.e. if these parameters are all 0 then I can get my code to take the parameters from CurrentDate$ - nice one. :) Thanks to all. :) |
| ||
| Null only makes sense from an object based reference. If you want to have "undefined" Ints, wrap them in an object. |
| ||
| Make your default values an arbitrary date 01/01/1970 or something. |
| ||
| Why Dont you only create an instance of the class/object, AFTER you have the details. Then when you create it you add the details, and then can be sure that you never have a null instance (To be honest a Null Instance sounds stupid anyway ;) The main difference to what you are doing is that the values are passed to member function of the type/class, rather than to a member method. Normaly Type Type1 field Field1:int Function Create:Type1(Val:int) temp:Type1 = new Type1 temp.Field1 = Val return Temp endfunction endtype Global Instance:Type1 = Type1.Create(Val:int) Because the function is not attatched to a specific instance of the type, (Its part of the type itself), wether Field1 is NUll or not is arbitary, because the INSTANCE doesnt exist until after you have given it the values. I assume you have somthing like Type Type1 Field Field1:int Meethod SetField1(Val:int) Field1 = Val endMethod endtype Global Instance:Type1 = New Type1 .. .. Instance.Setfield1(Val:int) In this case the method to set the fields belongs to the instance of the type, not the Type itself. This Means that the instance exists with either No values or arbitary values, hence the problem Por supesto I might be wrong |
| ||
| WendellM Silly question but how do you know the Gregorian calender starts in the year 0001 rather than 0000? I'm hoping this over-sight on my part is not going to mess up my code - it's should not. |
| ||
| There's a good amount of info here: http://en.wikipedia.org/wiki/Year_zero confirming that the Gregorian calendar has no year zero (but also mentioning how astronomers use 0 for 1 BC and bump all the other BC years accordingly for ease of calculation). |
| ||
| WendellM, Thanks again, very useful link for me. :) |
| ||
| Okay, gone back to my code and started changing things - and trying to make sure I don't break something in the process! I have another method in my type that basically returns a count of days since day 1, which I was intially taking as being 1-Jan-0000. Would we now agree that day 1 of this count should start on 1-Jan-0001, i.e. 366 days less than it would have been previously? |
| ||
| deleted |
| ||
| Glad that was helpful, Blitzer101. However, now you're venturing into a more difficult realm.... Date calculation stuff going back to year 0001 is pretty hairy! These are much murkier waters than how to represent null values in function/method calls. ;) For example, will you be assuming that dates before the adoption of the Gregorian calendar which occured in different years in different locations between around 1582 and 1752 are passed to your functions/methods as Gregorian, rather than Julian, dates? And will you be using the Julian leap year rule for that period (which differs from the Gregorian one regarding century years evenly divisible by 400)? I believe that stickiness like this is why computer date converters fix their day counting from more modern dates (like the 1/1/1970 origin used by Unix and mentioned by tonyg above). That avoids the problem for dates after around 1700 since the origin date lies on the modern side of the Gregorian changeover, so only the simpler, Gregorian rules need to be used to calculate days elapsed between two dates (unless you need date intervals back to the pre-Gregorian era). You can see some of the issues that otherwise need to be addressed here: http://en.wikipedia.org/wiki/Julian_day and here: http://www.wilsonmar.com/datepgms.htm (where you can see the various approaches used by other programmers) So as for your question of whether day 1 of your count should start on 1/1/0001 (if you want to go back that far) rather than 1/1/0000, I'd say yes. As for whether that's 366 days later, it is if year 0000 is taken to be the leap year 1 BC as astronomical reckoning does (otherwise the number of days later is meaningless, since there is no year 0 in historical reckoning). However, as you'll see in the links above, it unfortunately gets more complex from there depending on how you want to calculate the number of days elapsed from that origin to modern dates. However, even if you decide to limit things to after the Gregorian changeover, you could certainly still use the "Mymethod (DD=0, MM=0, YYYY=0)" approach to trigger whether to use CurrentDate(). |
| ||
| WendellM, Damn it you are right aren't you! LOL :) Rather stupidly although I'd come across the info regarding who where and why various countries etc. adopted the Gregorian date at different times I was so engrossed in the info I was looking for that I totally failed to take this into consideration. As I have it ATM my calculations all work on the basis that the Gregorian calender was being used from 1-1-0001 which as you point out is not really correct even if it will produce the required results for modern dates. I suppose the only thing this really messes up is using 1-1-0001 as equal to 1 for my day count. Not sure if this really is a problem though as it's only a counter at the end of the day to be used for calculating differences between dates mainly. I guess there would be no harm in continuing to use that as the start point for the counter but perhaps limiting my code as in to how far it will allow you to go back in time. e.g. I could limit the start date at which the various methods work to say 1-1-1800? Does that sound like a sensible approach? Not as if I'm trying to create the be-all and end-all code for dealing with dates, just trying to provide something a little more extensive and useful than CurrentDate$ alone. Any suggestions with regards to the design and functionality much appreciated. :) |
| ||
| As I have it ATM my calculations all work on the basis that the Gregorian calender was being used from 1-1-0001 which as you point out is not really correct even if it will produce the required results for modern dates. Maddening, ain't it? :) What's so annoying is that, unlike linear/weight measures which are easy to convert, you can't just put in one conversion and be done. The old records have dates using a devil's brew of dating systems which, unfortunately, look like the modern standard and which create an interesting philosophical problem. For example, the Russian Revolution is known as the October Revolution since it took place in that month in 1917 according to their calendar (which was pretty much the last holdout and didn't change over to Gregorian until 1918). But the revolution was in November, 1917 according to the rest of the Western calendars. So, when did it "really" happen? Since Russia now uses the Gregorian calendar, going backwards you'd think that it'd be November. But then again it's so well entrenched in history as the "October" Revolution and was according to the calendar of those revolting and being revolted against. Enough to make your brain go in circles! There's something about time that seems to make it special. Converting from feet to meters seems to leave the actual length unchanged, but somehow calculating backward a certain number of days using our modern calendar to a pre-Gregorian date and having the result not match the date that everyone at the time was calling that day seems wrong. It may be related to the intricate relationship of months, days, and years present before and after the conversion that makes that harder to accept (unlike the decimal precision of a single number in meters which seems like an improvement on foot/inch clumsiness). And don't even start on the differences of solar days and sidereal days... :) I suppose that it comes down to who the intended audience for these functions is. If it's programmer types like Blitzers rather than astronomers or historians, then they'd probably appreciate a set of date functions that impose an invariable, iron-clad Gregorian date structure on the past. In that case, you'd probably want to set your "day 1" (or maybe "day 0" since it's for programmers) to some recent point to avoid the Gregorian changeover. It doesn't really matter when, since it'll presumably only be used internally, so you could get creative. Your (or Mark Sibly's) birthdate? When BlitzMax was released ("Anno BlitzMaximi")? :) Then just employ ruthless Gregorianism to determine all future and past dates from there - historical records be damned! :) If you're sufficiently careful with leap years and such, it could be a nice set of functionality. So, for what it's worth, that's what I'd recommend. Some folks won't like it no matter what you do simply because there is no truly "right" answer. But I'd accept strict Gregorianism (complete with its illogical 1 AD -> 1 BC jump with no intervening 0) because it's the system currently used in the West. (If you really wanted to get extreme, you could provide options for astronomical/julian dating and other calendars like Jewish and Mayan, but that's probably going too far afield and you'll doubtless have your hands full just dealing with the Gregorian problems of variable-day months and leap years.) Sorry for rambling - I just find all of this interesting. I took the opposite approach many years ago and wrote a little program to calculate modern dates using the Julian/Roman calendar. It was fun to arbitrarily impose the unreformed dating system on the modern world, complete with starting from the founding of Rome (1 a.U.c.) and using the Ides, Nones, Kalends, and Pridie, even though it fell further and further out of synch with the actual seasons on Earth. |
| ||
| Yeah, to a point it really won't matter what I use as the starting date. Sure, this will mean that at various points for dates in that the past the date will effectively become completely wrong. However, you could argue that on the same token it would be correct from a Gregorian date point of view, i.e. had the Grogorian calender been in use since 01-01-0001. Looking back on our discussion and how my code works ATM, there's almost little point in actually not using the date count starting from 1-1-0001, particularily if I point out in the docs for it about the complexities of calenders! As I've said all along, I'm not trying to provide the be-all and end-all for using dates, I just want to make life a little easier for fellow BM'ers to manipulate dates in the software they create without having to resort to creating their own routines. I have to say that, complexities of calender issues aside, most things I've tried to do with regards to dates have ended up much simpler and more straight forward than I'd expected. Silly things like expecting code to be much more complex for doing things like testing for leap years or calculating what day of the week it was on a given date turned out to be really quite straight forward. Anyway, enough of me waffling on - back to doing some coding methinks. Thanks again - please feel free to throw more spanners in works if you think of anything else that might be of use or perhaps how or what functions you think would be useful? :) |
| ||
| there's almost little point in actually not using the date count starting from 1-1-0001 Say, you're right. If it's "Gregorian all the way" then there's no changeover barrier to worry about going through and 1/1/0001 is the logical starting point. I'm not trying to provide the be-all and end-all for using dates, I just want to make life a little easier for fellow BM'ers to manipulate dates That is indeed a good idea and that sort of thing could be handy. what functions you think would be useful? Right off, just some obvious ones that you probably already have in mind: days between two dates, day of the week for the specified date, whether the specified year is a leap year (True/False). Maybe the number of days in the specified month. Perhaps returning the DD/MM/YYYY format for the specified Nth day of the year (and vice versa), as well as N days before/after a specified date. I'll let you know if any others come to mind. |
| ||
| I suppose it might have helped if I posted what it can do so far, I still have other things planned but not even started looking at them yet! :) Anyway, here we go this is what I have so far... All parameters in <> are optional. If "datestring" is omitted then the system date is used. If DD, MM and YYYY (where applicable) are all omited then the system date will be used. Where appropriate leap years are tested/allowed for. year% = date.Year(<"string">) ' returns year as a number from "string" - Used internally to get value from CurrentDate$ month% = date.Month(<"string">) ' returns month as a number from "string" - Used internally to get value from CurrentDate$ date% = date.Date(<"string">) ' returns day number of month as a number from "string" - Used internally to get value from CurrentDate$ lengthofmonth% = date.DaysPerMonth(<MM,YYYY>) ' returns number of days for month MM in year YYYY. leapyear% = date.IsLeapYear(<YYYY>) ' returns True/False if year YYYY is leapyear or not. dayofyear% = date.DayOfYear(<DD,MM,YYYY>) ' returns number of day in year starting at 1 for Jan 1st. daystoyearend% = date.DaysToYearEnd(<DD,MM,YYYY>) ' returns number of days from date provided until end of that same year. daycount% = date.DayCount(<DD,MM,YYYY>) ' returns a count of days using the Gregorian calender exclusively. Count starts with day 1 being 1-1-0001 daysbetween% = date.DaysBetween(fromDD, fromMM, fromYYYY, ToDD, ToMM, ToYYYY) ' returns count of days between two dates. I'm liable to drop this method as it's just as simple to use DayCount(<1st Date>)-DayCount(<2nd Date>) dayname$ = date.DayName(<DD, MM, YYYY, True/False>) ' returns day name (mon, tues) etc. from date given. Optional parameter (True) returns long day name e.g. Monday. Default (False) returns short day name e.g. Mon Also planned... weeknum% = date.WeekNumber(<DD, MM, YYYY, OFFSET>) ' returns week number 1-52 for given date. Not decided whether or not to bother with the OFFSET parameter yet - might be over-kill. datestring$ = date.Format(DateCountValue, <"string formatting parameters">) ' return a user defined date string from the DateCounter value. i.e. give user freedom to return date the way they want, e.g. Sat, 20-May-2006 or Saturday - 20/5/2006 etc. Really not looked at this last one very much yet and it will be left until last as it's possibly the most challenging part. :) No doubt I've forgotten something there, but you get the idea I hope. Then end idea is to have all that functionality and make this into a Module so these methods all become commands within BM. Mind you I have to suss out how to make Modules yet as well LOL. :) |
| ||
| BTW, is there some info in the forums about posting code as I've seen inside listboxes in blue text and quoting text from other posts? Cheers. :) |
| ||
| I know, I had that page as a link in me Favorites, But by stupid registry cleaner.. err cleaned it. Ive been looking for it. It should be one of those pages thats easy to find |
| ||
| this is what I have so far... That's looking good. As for quotes and code boxes: What are the forum codes? |
| ||
| As for quotes and code boxes: What are the forum codes? Thanks for that. ;-) |
| ||
| Doh! Just when I think I've got past the tricky bits due Gregorian calenders etc. I now find I have new issue with week numbers! LOL. I stupidly was thinking week 1 of a year would always start on the 1st of January - of this clearly is not true/possible as 365 does not divide equally by 7, it's either 2 or 3 days extra, i.e. 52 weeks plus 2 days or plus 3 days for a leap year. Hahaha. I think this is going to drive me mad. :) Oh well back the drawing board with regards to the calculations, thankfully week 1 of this year did start on 1st Jan so at least I can work back from that. :) Scrub that, 1-1-2006 was week 52, week 1 started on the 2nd. Having a complete mental block ATM - just can't get my head around where I'm starting with this week number lark. :( |
| ||
| Argh! I should have known this would get more complex than I expected. I really need a kick up the butt for not checking out week numbers on the net as well. Just when I thought I got it sussed I discover that it's still not right. :( This is one method/function that I thought would be really quite straight forward and fairly easy to do, but instead I've pretty much spent the whole day trying one thing or another. Finally thought it was sorted so went about testing other dates only to find I'm way out. I think it's probably a case of trying to be too clever with my calculations, mind you I did not realise that you do have a week 53 at times as well! LOL. Methinks I need to have a break from this - remind me never to mess with date stuff again! :) |
| ||
| Back To the NULL thing. Null doesnt have a value, It changes the Object/Type to Point to NULL. Its like saying, I want this label to exist, but I dont want it to point to anything. (if it pointed to anything then the thing it pointed to couldnt be garbage collected) E.g. Type LEVEL endtype Local GameLevel:Level Now at This point we have a lable "GameLevel" of type Level. It doesnt give us directions to a Level (Ie doesnt "point" to anything, it points to "The Nothing","The Void","The Null") Now later we want to do some stuff with GameLevel, But we cannot be sure that it point to anything "Real" yet.. so If Not (GameLevel = NULL)........... Now at this point I believe you think that it looks at the value of null and sees if it the same value as GameLevel Well Why would it bother? It just looks to see if they point to the same place. (Cos if they do they are the same) So to sum, asking what the value of NULL is, is a conceptualy wrong question. You can do it, and get an answer. But its still wrong NULL is a pointer to the void. The compiler should really give an error if you ask for the value of Null. |
| ||
| Ah, but I was not actually trying to ask what the value of Null was - excuse the subject title! What I was really trying to do was say the default value of a variable should be NULL, i.e. have no value as opposed to having a value of 0, despite 0 being nothing if you see what I mean? Not to worry though, I saw quite a way back that this was not correct or possible and have since found a simple and effective way to achieve what I set out to do. :) What I'm totally stuck with ATM is trying to determine whether a year has 52 or 53 weeks in it. For some reason this is just causing me (and anyone around me!) a major headache. It sounds so simple, yet actually trying to work out a formula to give the required/correct result is a complete nightmare. Got as far as finding out that if the 1st of January falls on a Mon, Tues, Weds or Thurs then that week is week 1. If the 1st of Jan falls on the Fri, Sat or Sun, then the week is week 52 or 53 of the previous year. It's the actual calculation of detemining 52 or 53 that is causing so much of a problem. You always find yourself almost going round in circles as it seems you need to know how many weeks there were in the previous year. If any one has any suggestions how to do this please feel free to post! Pleaaaaase! :) |
| ||
| When you try to get the Value of NULL the compiler should give an "Attempt to access NULL object" (Which Lokking back at your first post was your point. doh) What Do you Mean A "Week" 1) Seven Days 2) Sunday to Saturday If You mean the first one then every Year has MORE than 52 Weeks BUT <======== (If we had a bigger font then I would use that) Why are you bothering? Unless you have a Time Machine or some such, No one is going to go back and see. So just make it up. Get it consitent to ... I dont know 1901, but after that just apply the same rule, (irrelivent of if its right or not) As long as its correct going forward, who's going to Know? |
| ||
| H&K, What Do you Mean A "Week" Neither 1 or 2 it would seem! LOL. Some calenders have week numbers on them yes? Thing is week 1 of a given year is not necessarily 7 days long, it could actually be just 4 days long. Not only that but depending on what date the first Thursday of the year falls on will also effect how many weeks there will be in that year. However, my latest thought is that it gets more complicated than that as it would also seem that the date on which the first Thursday falls in this year also plays a part in how many week there were in the previous year. Why are you bothering? Unless you have a Time Machine or some such, No one is going to go back and see. So just make it up. Because week numbers are used on calenders and I'm trying to create a Module (eventually) for BM that will provide far more date functions than just CurrentDate$. The problems really revolve around trying to determine if a given year would have 52 or 53 weeks in it and the how many days there are in week 1 which is governed by the position of the first Thrusday relative to the begining of the year. Not only that but week 52/53 can actually take part in the next year as can week 1 I believe. =-s It would seem that to determine the week numbers for a given year you also need to calculate where the first Thursday of the year before and the year after started. I know this must sound a lot more complex than you'd think but trust me it is! :) I just wish I could explain a little better. :) |
| ||
| Again, why are you botering (The specifics are why are you bothering to make it accurate 2000 years ago) Just make it accurat for modern days (let say after you where born) From your answer I cannot belive that you are saying some years have 52 weeks. If the year starts on day one of week one, it ends on day one (or two for leap years) of week FiftyThree. ALL years therefore (Taking you deinition of week) have 53 weeks If you are going to bother, stop trying to figure out a relationship between years and weeks. The realationship is days and weeks. If a date was 12,324,345 Days ago (12,324,245 Mod 7) = 5. Monday- 5 = Wednesday. If the date is 800 days from now (800 mod 7) = 2 Monday +2 = Wednesday AGAIN no one is going to go back to 1726 to see if you included the cahnge in calender, so just ignore in. So 01/01/01 Is day one (Monday 1st Jan 2001) Date later 22/05/06. Days = change from 01 to 06 = 365*5+1 (One leap year)=1,826 + Change from 01 to 05 = 31+28+31+30 = 120 + Change from 01 to 22 = 21 = 1,826 +120 + 21 = 1967 1967 mod 7 = 0 => the same day of the week So the 22/05/06 is a Monday The Month started 21 days earler (21 mod 7)= 0 so a monday as well. The year started (120+21) days earler so Monday - 1 = Sunday etc |
| ||
| Right for a kick-off it seems some of the info I was reading was miss-leading to say the least and gave me the impress that week 1 might only have 4 days. It seems this is not the case but what can happen is that the first 3 days of week 1 can actually take place on the last three days of December, this should make things a lot more straight forward. :) From your answer I cannot belive that you are saying some years have 52 weeks. If the year starts on day one of week one, it ends on day one (or two for leap years) of week FiftyThree. ALL years therefore (Taking you deinition of week) have 53 weeks What you say is very true if you you are looking at a period of 365 days (or 366 leapyear naturally). 52 X 7 = 364. However, week numbers are defined by ISO 8601, not the calender (Gregorian) as we know it. What we're dealing with is blocks of 7 days but these blocks don't ncessarily start with Jan 1st being the first day of week 1. It would appear that a week 53 occurs every 5 or 6 years (there is a pattern to it) looking through the calender on my phone. What defines week 1 as week 1 is that it has it's majority of days in the start of a new year. The days are defined as day 1 being Mon through to Sunday at day 7. This means that week 1 will always have a Thursday in it because it falls exactly between either end of the ISO week. Now, if we go back to what you are (correctly) saying is that each year has 52 whole weeks and 1 extra day (2 for a leapyear), we can see straight away that we have a problem - what to do with the extra day(s)? From what I can see now, I'm now thinking that the extra day(s) is/are counted as being part of week 1 of the following year unless this would mean the first Thursday of the following year would then not fall into week 1. In this instance a week 53 (i.e. another block of 7 days) is slotted in to pad things out and make the 1st Thursday of the following year fall within week 1. e.g. The 1st of January 2001 was a Monday, i.e. day 1 of week 1. Naturally, this meets the rule of the first Thursday falling into week 1. Our block of a full 52 weeks therefore ends on Sunday 30th Dec 2001 and we now have 1 extra day. As the 1st Thursday of 2002 would still fall into week 1 (it was the 3rd naturally), we don't need to start a 53rd week. Instead Mon 31 Dec 2001 becomes day 1 of week 1. This keep repeating until the 1st Thursday of week 1 would fall on 31 Dec. When this happens a week 53 is slotted in to pad things out and make the majority of week 1 take place in the begining of a year - not at the end of the previous year. I hope that makes sense, I've been kinda working this out as I go along and explain as clearly as I can. In a nutshell we need to change time itself so that each year is exactly x long and can be divided up equally. That would make life much easier! :) Thanks for your input though, it has at least made me look at the problem for various different angles. ;-) Now that I've cleared up my miss-understanding of what I read elsewhere and have worked out why and when a week 53 is needed everything should start falling into place. :) |
| ||
| I give up - what IS the point - nothing sodding works why the hell can't I just get this sorted. Just constantly going round in circles for seomthing so sodding simple it's unreal! |
| ||
| Dude, please chill out... :) I know how frustrating it is to bang your head against a problem like this, and I sympathize, but if it were easy, anyone could do it - the difficulty is what makes it worthwhile. First off, it's never occured to me to wonder how many weeks were in a specific year (the thumbnail of 52 works well enough for my purposes). Secondly, I'd never heard the "ISO 8601 week" until you mentioned it. So, I don't think that you'd need to scrap the rest of your project just because the week counting business doesn't work out: the other functions sound useful even without it. However, since the first week of the year is defined as the week with the year's first Thursday in it, wouldn't counting the number of Thursdays in a given year thus give you the number of ISO weeks in that year? (Forgive me if you've already gone over this approach.) If nothing else, a brute-force iteration of all days in the year (1-365/6) run through your day-of-the-week function while incrementing a counter for each "Thursday" returned should do the trick (unless I'm overlooking something). By assigning the week number based on how its Thursday falls, then all the other days of that week share that week number, no? I can't see your code, so I don't know if looking at it this way helps. But as a last resort, just set the week numbering business aside - it doesn't strike me as that big a deal to tear your hair out over. |
| ||
| Yeah, just had several days of working on this now and each time I think I've got it sussed it starts falling apart on me again. Just really had enough of it last night - calmed down a bit now though. :) The crazy thing is I never expected this part of the code to pose any problems compared with some of the other bits I've already done which I expected to be much harder. Secondly, I'd never heard the "ISO 8601 week" Basically on some calenders you have week numbers, I use them here at work in a manufacturing company. As I said the week 53 lark comes into it to effectively pad out a year so the first Thursday of a new year falls into week 1. Silly thing is that although I now understand how the week number system works I'm still going round in circles determining the start/end points of weeks 01, 52 and 53 and in particular their relationship as the year end changes over. As I said it just seems so crazy because on the face of it it apears so straight forward. I'm clearly missing something - several brains cells ATM it would seem. I'd really like to get it sorted because doing this date thing has given me an idea for a little project. However, since the first week of the year is defined as the week with the year's first Thursday in it, wouldn't counting the number of Thursdays in a given year thus give you the number of ISO weeks in that year? I'll look at it again like that, but I'm not sure that's even what the problem is, more to do with the change-over and determining the dates in relation to the week numbers. My head's pretty much mush ATM on this so forgive me if I ramble or don't make a lot of sense! LOL. Cheers. :) |
   |