Relevant Computerphile: https://www.youtube.com/watch?v=-5wpm-gesOY
Never write your own date parsing library
41–50 of 333 posts
Re: Never write your own date parsing library
#42I used to work at a company that stored all dates as ints in a YYYYMMDD format. When I asked why, I was told it was so we could subtract 2 dates to get the difference. I asked them why they couldn’t use DATEDIFF since this was in a sql db. They said they hadn’t heard of it and that it must be new.
In mainframes, Julian dates are popular for that reason. YYDDD (day of year).
When is 30 days after today? 25206+30
Re: Never write your own date parsing library
#43Earlier quoted context omitted.
> people’s birthdays changing when they move timezones That's because the developers use datetimes (aka timestamps) to store a single date. Just pick an arbitrary epoch date (such as January 1, 1900 as used by Excel, or my favorite January 1, 1600 since 1600 is a multiple of 400 making leap year calculations even simpler) and store the number of days elapsed since then. The rules involving leap years are much much si…
No, don't do that. Use a date datatype (not date/time). You aren't the first person to ever need to handle dates without times/timezones in a computer program. Use what your database/language/libraries already have to support that.
Well, for hardcore chronology Julian dates are what you do.
https://en.wikipedia.org/wiki/Julian_day
which are the moral equivalent of Unix timestamps with a different offset and multiplier. These work OK for human history but will break if you go far enough into the past or the future because uncertainty in the earth's rotation adds up over time.
If you don't care about timezones timezones may still care about you, if you want to minimize trouble it makes sense to properly use timezone-aware Zulu (GMT) dates for everything if you can.
In certain cases you might be doing data analysis or building an operational database for throttling access to an API or something and you know there are 16-bits worth of days, hours, 5-minute periods or something it can make sense to work relative to your own epoch.
Re: Never write your own date parsing library
#44Re: Never write your own date parsing library
#45In 2009 I made a note that Excel's main date parsing function was over 1000 lines of code -- not including helpers.
Re: Never write your own date parsing library
#46Earlier quoted context omitted.
> in the format 02/18/1993 Is this DD/MM/YYYY or MM/DD/YYYY? I can tell from the 18 that it's the latter, but that convention isn't universal. I'd recommend YYYY/MM/DD as a less ambiguous format, but I don't have a perfect answer.
Every time I see an input date string in XX/XX/YYYY format I get a micro PTSD flashback. This cannot be parsed reliably and is locale dependent. The standard date format is YYYY-MM-DD (it's also the date part of the ISO time format). Raw text inputs should be avoided as much as possible, date/time pickers should be preferred.
Even worse with just two digits for the year! 01/02/03 could be 1 Feb 2003, or 2 Jan 2003, or 3 Feb 2001. Let’s just be thankful no one ever uses any of remaining three permutations.
Re: Never write your own date parsing library
#47Earlier quoted context omitted.
Those ISO-8601 dates are great for date processing with primitive tools such as GNU sort or awk since they sort lexically, at least if you're not comparing dates in different time zones.
ISO 8601 is the way .
You must mean RFC 3339.
Re: Never write your own date parsing library
#48It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"
It's funny to reason why we must go to bed when the clock has a certain number, since modern technology could easily be programmed to adjust as needed. No technical reasons the Martians can't go to bed at 9:00am today and 9:40am tomorrow. This mirrors my thoughts on why farmers caring about daylight savings time is farcical, farmers I know use the timekeeping of "crack of dawn" and "sunset".
People want to understand when things are open/reasonable without having to do a lookup every time. A conversion has to happen somewhere - either I can say "X is in timezone foo. It's 1300 there so they're awake and I can call them" or "It's 1900 UTC, X is awake from....err....2200 to 1400, so I can call now".
The first is significantly easier as it requires remembering only a single offset and then going with societal conventions.
Re: Never write your own date parsing library
#49It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"
Every time someone mentioned "days" or "months" or "years" in Andor I had to mentally zap my brain not to think about how it doesn't make a sense across a galaxy.
Re: Never write your own date parsing library
#50It's like that joke someone posted on Twitter: "I was in favor of space exploration until I realized what it would mean for date/time libraries"
It's funny to reason why we must go to bed when the clock has a certain number, since modern technology could easily be programmed to adjust as needed. No technical reasons the Martians can't go to bed at 9:00am today and 9:40am tomorrow. This mirrors my thoughts on why farmers caring about daylight savings time is farcical, farmers I know use the timekeeping of "crack of dawn" and "sunset".
iirc DST was never about farmers, and always about energy usage (lighting, etc) in the evening
Agree I've never met a farmer who cares about DST. Though also, for non-ag farmers, sometimes "crack of dawn" isn't early enough lol. Cow: "Dairy barn has electric lights, why aren't you awake at 4am tending to my needs, Human? Vacation? Lol no, stay here. Every morning. 4am."