61–70 of 333 posts
It'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.
Earlier quoted context omitted.
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,…
I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…
I like how Temporal[0] does this. What you were dealing with is Temporal.PlainDate[1], i.e. a date with a calendar associated but no time or timezone (might be due to being implied but also might be irrelevant, like in birthdates). Temporal has other cool types, each with distinct semantics: - Instant: a fixed point in time with no calendar or location. Think e.g. "the user logged in at X date and time" but valid acr…
I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…
> 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…
Didn't the article explicitly tell us not to write our own date parsing library?
Earlier 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.
Strictly, it is the extended form of the ISO 8601 calendar date format. (The basic format has no separators.)
ISO 8601 allows any of its date formats (calendar date, week date, or ordinal date) to be combined with a time representation for a combined date/time representation, it is inaccurate both to call any of the date formats part of the time format, and to call the calendar date format the format that is part of the combined date/time format.
(There's a reason why people who want to refer to a simple and consistent standard tend to choose RFC-3339 over ISO 8601.)
Earlier quoted context omitted.
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.
Vernor Vinge had it figured out in A Deepness in the Sky with the use of kiloseconds, megaseconds, and gigaseconds.
That doesn't make it unusable as a cross galactic time unit, and I think the same goes for years and hours.
I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…
You seem to have a reasonably expedient solution for that problem, but it is surprising to have the combination of things you have to have and things you have to be missing to have that problem in the first place.
Earlier quoted context omitted.
Vernor Vinge had it figured out in A Deepness in the Sky with the use of kiloseconds, megaseconds, and gigaseconds.
A second is still originally defined as 1/86400 of an Earth day. That doesn't make it unusable as a cross galactic time unit, and I think the same goes for years and hours.
I ran into date heck recently in a medical setting for storing birthdates. Eventually I settled on the idea that a birthdate isn’t a physical time, it’s just a string. We can force the user to enter it in the format 02/18/1993 leading zeroes and all, and operations on it other than string equality are invalid. We’ll see if this survives contact with the enemy but it’s already going better than storing and reasoning a…