 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : DATE$ bug?
Page 1 of 2   |
|||||
| Author | Message | ||||
Oldbitcollector Senior Member  Joined: 16/05/2014 Location: United StatesPosts: 172 |
Have I stumbled over a bug? I can set DATE$ to anything up to 09-12-2014 any date beyond that, 09-13-2014 - 09-30-2014 is rejected. The problem appears to solve itself, (at least for a while) at 10-01-2014. Jeff My Propeller/Micromite mini-computer project. |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6224 |
Think Australian Dates! dd-mm-yyyy Jim VK7JH MMedit |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Jeff Australia uses a different date format from USA. Try dd/mm/yyyy. The manual is quite explicit about the format. I think they are all a bit irrational. I prefer yyyy/mm/dd debate anyone?? Bob |
||||
| Oldbitcollector Senior Member Joined: 16/05/2014 Location: United StatesPosts: 172 |
Wow.. I actually read right past that! TWICE.. Thanks for setting me straight. Yes, we Americans do tend to do things very strangely here. Drive on the wrong side of the road, and use the most ridiculous system of measurement. I'll make sure I start using the "correct" format for date from now on. Yes, +1 for yyyy/mm/dd.. My Propeller/Micromite mini-computer project. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9502 |
I prefer the current DD/MM/YYYY arrangement, but that is just cos this is what we use here, so I am comfortable with how it is. Had I been born and lived in the United Stated, I would be just as comfortable with MM/DD/YYYY. Everything is relative! 
Would it be worth Geoff perhaps having yet ANOTHER option command for the date format? OPTION DATE 1 for DD/MM/YYYY, and OPTION DATE 2 for DD/MM/YYYY kind of thing? HOWEVER - it's not really needed, so long as you know the date format. With that and MID$, you can re-arrange the date anyway you like, such that you could have something along the lines of: DATE_USA$=MID$(DATE$,4,3) + MID$(DATE$,1,3) + MID$(DATE$,7,10) DATE_USA$ will have the American format - 09/24/2014 for today, for example. You could do the same kind of thing in reverse, for setting the date - just ask for the month, date and year in separate variables, then combine them, and submit them to DATE$ EDIT: Fixed syntax errors - sorry.  Smoke makes things work. When the smoke gets out, it stops! |
||||
Justplayin Guru Joined: 31/01/2014 Location: United StatesPosts: 327 |
Since it seems like no matter what format the date is in it always needs to be reformatted, I think I would prefer yyyy/mm/dd. It's just easier to use for date comparisons and sorting. But in the end, it doesn't really matter, because you still end up chopping it up into your favorite format to display it anyway. --Curtis I am not a Mad Scientist... It makes me happy inventing new ways to take over the world!! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6224 |
Being of Pommy heritage (a few generations ago), I prefer to follow the lead set in the "Magna Carta" I have spent most of my programming life changing the "other" format into propper English so I think it's time that we got our own back. For timestamping I do use yyyymmdd to make sorting easier. There are other choices Jim VK7JH MMedit |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2927 |
Blimey, thats where I live!! 
I prefer yyyy/mm/dd (easier for sorting) |
||||
Lou Senior Member Joined: 01/02/2014 Location: United StatesPosts: 229 |
Lets concentrate on the "Real Date", Stardate 2014.266 (for Sept 23, 2014). Lou Microcontrollers - the other white meat |
||||
Gizmo Admin Group Joined: 05/06/2004 Location: AustraliaPosts: 5111 |
Dont get me started on the USA date format 
Oops, too late. As a software developer, I think of the MM/DD/YYYY format as the biggest pain in the bum I once had to deal with. Especially when dealing with databases, and its a big trap for beginners. The problem is a database, Access for example, will assume you are using the USA format ( MM/DD/YYYY ), even though its on a device with another countries regional settings. Most of the time  . If I ask a database to return records with a date of 1/1/2014, it returns records from 1st January 2014. If I ask for 2/1/2014, it returns data for the 1st February 2014!!! Fair enough, it wants a USA format. But if I ask for a date of 13/1/2014, the database thinks "this is not a USA date, lets try something else", and returns data for 13th January 2014. So it basically cant be trusted to return the right records, because it changes format until it finds one that works.
The solution is to use a long date format like "13 January 2014", which it cant mess up. But, if I ask the database to give me the date for a record, it returns the date in the regional format, not the USA format. So to reliably talk to a Access database, you insert/update or query records in a long date format, but the result is in a regional format.
I've also seen this problem pop up with expiry dates on chemicals and medicines. "1/10/2014" could mean it expired on the 1st October, or the 10th Jan. Big problem. I prefer the format of YYYY/MM/DD which cant be stuffed up. Yep, its a pet hate. Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
ISO 8601 specifies date in YYYY MM DD format and like GIZMO the US vs Europe/Australia/NZ data format has caught me out so many times, I learned to just use and insist upon ISO date and time formatting. 73 Peter The only Konstant is Change |
||||
| Gizmo Admin Group Joined: 05/06/2004 Location: AustraliaPosts: 5111 |
Big NO from me. 2 reasons, 1. Its an Australian developed chip, so should stick with Australian conventions, and 2. I think of it as revenge for all the times I was caught out by the USA date format 
Glenn The best time to plant a tree was twenty years ago, the second best time is right now. JAQ |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9502 |
Ha, ha, ha - fair enough, Glenn!
I was going to mention Stardate, but Lou beat me to it!
In my MaxiMite system which logs any calls on the system to a daily logfile, I just use a nice simple 7-character filename representing the date: 24SEP14.LOG for today, for example. That is nice and easy to understand, and even our American chums should be able to follow that without getting confused.  Smoke makes things work. When the smoke gets out, it stops! |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
So that would be September 14 in the year 1924? :) My preferred way is 20140924. I found it to be the most useful for log files to be able to batch process them and sort them easily. Microblocks. Build with logic. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2927 |
Don't be silly, its obvious it's the 24th Sept 1914 |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1427 |
Amen. I use ISO 8601 as often as I can. I've been an annoying advocate of that for years. Micromites and Maximites! - Beginning Maximite |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2946 |
Geoff, Please don't change the date format.. If we Aussies have to learn that brownies are cakes and the alphabet ends x, y, zee and that cakes are covered in Frosting instead of icing then the rest of the world can learn some aussie 'standards' Gawd, strewth, strike me hooray sport.. Fair dinkum cobbers Regards Mick. (Obviously tongue in check)
Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Mick If anything, the Date Time format should be ISO8601, that way it's above national and cultural (except for Japan) preferences, and is clearly the most logical, and unambiguous formats. I do seriously know of a project which came in months late solely because of the misunderstanding about DD/MM vs MM/DD, I can't remember exactly what, but it was something like, 6/8/2002 in Europe, but 8/6/2002 in the USA on the project plans. Needless to say the Americans were NOT very happy/amused when they found out the s/w was being delivered in August rather than June, and the European developers were even less happy/amused when they were "asked" to work day and night to bring the delivery date forward. Peter The only Konstant is Change |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9502 |
@ TZA and WW - Had not thought of that!
Looks like ISO8601 has merit, and, as has been pointed out by others, can't be confused. I guess these things only become an issue for the likes of MaxiMite/MicroMite, now that they have "Left the nest", so to speak, and are much more international now then they were in the beginning. Smoke makes things work. When the smoke gets out, it stops! |
||||
| BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
As I indicated in the first response to this thread, I think that the ISO form of date is the only rational one available. Like Gizmo, I am crapped off trying to figure out which date format I am dealing with at any instant and many times still not being sure if the month and day components are simultaneously less than 13. I think I'll start the "All Dates should be ISO" campaign. |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
