Does your janky string format of “18-03-2024” suddenly has to become aware of the timezone
No, there is no timezone, and that is the entire point. In the majority of cases you just want to store the local date. The point is that a local date or time is not necessarily a fixed point in time. If I have drinks at 18:00 every Friday, that doesn’t change when we switch to or from DST, it’s still 18:00 in local time. I don’t need a timezone, I know what timezone I live in.
Now, in cases where timezones do matter, for example if you have a Zoom meeting with someone from another country, you can store as local time + timezone. But this is still very different from storing a Unix timestamp. This meeting will be at a specific time in a specific timezone, and the exact moment in time will adjust when changes are made to that timezone. Again, a Unix timestamp does not allow for this, as it’s always UTC.
I assure you that 1710720000 will translate to the same janky “18-03-2024” format you’re using every single time unless you deliberately mess with timezones in code
No, it doesn’t. You can’t convert it to any date unless you “mess with timezones”, because 1710720000 is a specific moment in time and you have to provide a timezone when converting it to a date. You are mistaking the fact that some systems implicitly use UTC when converting for some sort of of universal standard, because it’s not.
Run the following Swift code:
let d = Date(timeIntervalSince1970: 1710720000)
print(d.formatted(date: .complete, time: .omitted))
You’ll get a different date depending on your location.
If your code will break because someone has different OS settings than yours, you are writing bad code.
Yes, and your bad code will break simply because you are abusing a datatype for something beyond it’s intended use. If you want to store an absolute point in time, by all means use a Unix timestamp, but if you want to store a local time you should never use it because it’s not mean for that and it doesn’t encode the information needed to represent a local time.
Even this would be better than a string:
struct { int year byte month byte day }
Yes that’s fine. I’m not arguing that you should store it as a string, I’m arguing that you should store it as individual components, in whatever format, instead of seconds since the epoch. As long as the format is well specced it doesn’t really matter. Strings are used all the time for representing dates by the way. For example, ASN.1, which is used everywhere, stores dates and time as strings and it’s perfectly fine as the format is specified unambigiously.
Six bytes as opposed to 10
In what archaic system are int’s still 4 bytes? Int is 64-bits, or 8 bytes, on any modern machine. If I read your format on a 64-bit machine, it’ll break. Also is that int little or big endian? You code still breaks if you spec an int32 and you store your date on an x86 machine (little endian) and I read it on a big-endian machine. You know what’s not ambiguous ? “This time is stored as an ISO8601 string”.
Dude, a date is a fixed point in time… just has less accuracy than if a time is included.
In what archaic system are int’s still 4 bytes?
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.
If I read your format on a 64-bit machine, it’ll break.
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.
You know what’s not ambiguous ? “This time is stored as an ISO8601 string”.
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.
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
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).
Interesting that you were boldly claiming that experts use a dd-MM-yyyy format
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.
No, there is no timezone, and that is the entire point. In the majority of cases you just want to store the local date. The point is that a local date or time is not necessarily a fixed point in time. If I have drinks at 18:00 every Friday, that doesn’t change when we switch to or from DST, it’s still 18:00 in local time. I don’t need a timezone, I know what timezone I live in.
Now, in cases where timezones do matter, for example if you have a Zoom meeting with someone from another country, you can store as local time + timezone. But this is still very different from storing a Unix timestamp. This meeting will be at a specific time in a specific timezone, and the exact moment in time will adjust when changes are made to that timezone. Again, a Unix timestamp does not allow for this, as it’s always UTC.
No, it doesn’t. You can’t convert it to any date unless you “mess with timezones”, because 1710720000 is a specific moment in time and you have to provide a timezone when converting it to a date. You are mistaking the fact that some systems implicitly use UTC when converting for some sort of of universal standard, because it’s not.
Run the following Swift code:
let d = Date(timeIntervalSince1970: 1710720000) print(d.formatted(date: .complete, time: .omitted))You’ll get a different date depending on your location.
Yes, and your bad code will break simply because you are abusing a datatype for something beyond it’s intended use. If you want to store an absolute point in time, by all means use a Unix timestamp, but if you want to store a local time you should never use it because it’s not mean for that and it doesn’t encode the information needed to represent a local time.
Yes that’s fine. I’m not arguing that you should store it as a string, I’m arguing that you should store it as individual components, in whatever format, instead of seconds since the epoch. As long as the format is well specced it doesn’t really matter. Strings are used all the time for representing dates by the way. For example, ASN.1, which is used everywhere, stores dates and time as strings and it’s perfectly fine as the format is specified unambigiously.
In what archaic system are int’s still 4 bytes? Int is 64-bits, or 8 bytes, on any modern machine. If I read your format on a 64-bit machine, it’ll break. Also is that int little or big endian? You code still breaks if you spec an int32 and you store your date on an x86 machine (little endian) and I read it on a big-endian machine. You know what’s not ambiguous ? “This time is stored as an ISO8601 string”.
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.