5 ms·

Double edged sword.. if they were to use 4 digit numbers, they couldn't use int32 to store YYYYMMDDHHMM. But.. they wouldn't be able to use int32 and therefore

• fendy3002 5y ago
  Why not using unix timestamp though? Is it cause they're MS?
  • munchler 5y ago
    Unix timestamp is hardly better, due to the Year 2038 problem. I think the only truly robust solution is to use a 64-bit integer instead.
    • mohaine 5y ago
      time_t solved the 2038 problem a long time ago
      • kristiandupont 5y ago
        ...not according to Wikipedia: https://en.wikipedia.org/w/index.php?title=Time_t&oldid=450752800#Implementation https://en.wikipedia.org/w/index.php?title=Time_t&oldid=4507...
      • baq 5y ago
        if you recompile the world, it did...
  • zarzavat 5y ago
    There's a difference between timestamps and dates. For instance Christmas Day is on 2022-12-25, but it doesn't have any particular time stamp as that depends on which time zone you are in. If you are making a calendar app, you want to store dates and not timestamps as, e.g. if I have a flight to another country then have an appointment at 9am, that 9am should be in the time zone of wherever I am physically present, which the calendar doesn't necessarily know. Storing as an integer is compact and allows for easy comparison. It's a clever hack, but they should have used 64 bit, or at least a u32!
    • asddubs 5y ago
      or put the month first (but of course that ruins easy sortability)
    • grishka 5y ago
      Calendar appointments are a good example where a timestamp without a timezone (java's Instant) is appropriate. But a birthday doesn't have a time, so you would want to use LocalDate (a date without a time and timezone) for that. In 99% of the cases you only really want to involve timezones when presenting something to the user or taking input from them. So you would create your calendar event by entering "9am, timezone X", and the app would most probably just apply that offset and store that as a timestamp. But if it's an all-day event... I should probably take a look at android's calendar content provider.
      • hiptobecubic 5y ago
        Not storing absolute times is a disaster. If it's seemingly working now it's only because your use case apparently doesn't include anything cross-timezone. Referring to something like "Christmas day" as timezoneless doesn't help either. Anyone who celebrates it celebrates it in a timezone. Christmas Day EST is a different event than Christmas Day CEST. Trying to represent them as the same event will only lead to heartbreak.
        • Jenk 5y ago
          Birthdays are an exception to this rule. Generally I think Dates (without time) are usually considered time-less and therefore timezone-less. In fact the examples you mention are only a concern when considering the start or end of Christmas Day, and not the actual date of Christmas Day.
          • hiptobecubic 5y ago
            The problem I see is that at some point you will try to decide whether it's currently Christmas or not. That's when things start falling apart.