this post was submitted on 17 Mar 2024
2714 points (99.2% liked)
Science Memes
11148 readers
4636 users here now
Welcome to c/science_memes @ Mander.xyz!
A place for majestic STEMLORD peacocking, as well as memes about the realities of working in a lab.
Rules
- Don't throw mud. Behave like an intellectual and remember the human.
- Keep it rooted (on topic).
- No spam.
- Infographics welcome, get schooled.
This is a science community. We use the Dawkins definition of meme.
Research Committee
Other Mander Communities
Science and Research
Biology and Life Sciences
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- !reptiles and [email protected]
Physical Sciences
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
Humanities and Social Sciences
Practical and Applied Sciences
- !exercise-and [email protected]
- [email protected]
- !self [email protected]
- [email protected]
- [email protected]
- [email protected]
Memes
Miscellaneous
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Dude, a date is a fixed point in time... just has less accuracy than if a time is included.
When you have more experinece in programming in more languages, you'll find that in a lot of modern languages an int is always 32 bit and a long is 64 bits. Doesn't change if your system is 32 bits or 64 bits.
And this is exactly why many programming languages don't change the definition of int and long for different processor architectures.
You clearly don't have any experience with higher level programming languages, which you should really look into. If you have so little understanding of the problems with dates and times you should really only work in languages that have a well defined DateTime structure built in so you won't get into trouble with all the various edge cases and performance problems you're creating by not understanding why parsing date strings should be avoided whenever possible.
Interesting that you were boldly claiming that experts use a dd-MM-yyyy format and now you're bringing up a format that starts with yyyy-MM-dd. Do you understand now why it's put into that order?
But yeah check out high level languages, they'll serialize dates into a standard format for you. Though I still have to put in serialization options to handle communications with partners that don't follow standards. Like all the time. I get enough headaches with just dates in a string formats when I can't avoid it that I know better than to do it when I can avoid it.
The meme you had that says that experts use dd-MM-yyyy is the wrong way around. Beginners use the built-in DateTime functionality that's offered by a high level language. Experts use this as well. It's only the mid tier devs that think they're going to come up with a better way on their own and get into the problems you're going to find yourself in.
Once you gain some more experience you will realize that ‘a lot of’ is not good enough. Some languages do, some don’t. If you define a format, you don’t say ‘int’, you say something like “int32 in network byte order” (a.k.a. big endian).
Stop being willfully ignorant. I’ll repeat it once more: my claim is that you should store your dates as individual components, not as a the time since an epoch. I don’t care how those components are stored as long as it’s clearly specced.