|
I was digging through a problem a client was having with some dates being rejected as in the future even though they aren't due to timezones (timezones can suck my dick by the way). That's not really the story though, that's just poo poo I have to deal with because every piece of software we integrate with uses a different method of dealing with dates when transferring data. The problem is that after digging for a while I started to look for info about our software and what it's supposed to do with future dates. Here's what I found: 4.0.1 - Future dates aren't allowed at all 4.0.4 - Future dates are allowed but if it's the last day of the month you can't put in the 1st of the following month (bug) 4.1.0 - Future dates are allowed in all cases 4.1.3 - Future dates are not allowed at all 4.2.0 - Future dates aren't allowed but future times on today's date are allowed (by design) 4.3.0 - Currently in development, no one can tell me whether it will allow future dates Digging through dev notes I see the same names coming up on both sides of the future dates argument over the years. door.jar fucked around with this message at 00:51 on Jan 7, 2012 |
#
?
Jan 6, 2012 11:00
|
|
|
|
| # ? May 21, 2024 04:20 |
|
|
door.jar posted:I was digging through a problem a client was having with some dates being rejected as in the future even though they aren't due to timezones (timezones can suck my dick by the way). That's not really the story though, that's just poo poo I have to deal with because every piece of software we integrate with uses a different method of dealing with dates when transferring data. Why would you ever not just use UTC for any and all datetime data?
|
|
#
?
Jan 6, 2012 20:34
|
|
|
Hammerite posted:Why would you ever not just use UTC for any and all datetime data? Timezones (and the joy that is DST) don't go away just because you're storing in UTC. Not that you shouldn't pretty much always store data in UTC, but that only makes your life a little easier.
|
|
#
?
Jan 6, 2012 22:19
|
|
|
Hammerite posted:Why would you ever not just use UTC for any and all datetime data? Even if we did, the other systems we have to interface with, which are up to 20 years old and we have no control over, won't and we'll still have to deal with timezones all over the place.
|
|
#
?
Jan 6, 2012 23:29
|
|
|
Timezones, weekdays, leap years and clocks are real life horrors. Ugh, corner cases.
|
|
#
?
Jan 6, 2012 23:34
|
|
|
moynar posted:Timezones, weekdays, leap years and clocks are real life horrors. Ugh, corner cases. Let me tell you about offsets that are not whole hours and therefor are not accepted as valid input in so many APIs.
|
|
#
?
Jan 6, 2012 23:39
|
|
|
Don't forget leap seconds and end-of-century common years. And regions that change whether or not they follow DST. And changes to the definition of DST.
|
|
#
?
Jan 6, 2012 23:42
|
|
|
UTC+13:45 is my favorite timezone offset. I once had the exciting task of adding support for it to a program which used a 3-character field to store the timezone and assumed that the max offset was 12.
|
|
#
?
Jan 6, 2012 23:51
|
|
|
If you think current time zones are bad, just have a look at historical time zone data. (It's a goldmine for history buffs, though.)
|
|
#
?
Jan 7, 2012 00:06
|
|
|
geonetix posted:Let me tell you about offsets that are not whole hours and therefor are not accepted as valid input in so many APIs.  I am absolutely confident that lives have been lost due to this. Somewhere, somehow, an airplane will explode when it passes a border with some DST corner case.
|
|
#
?
Jan 7, 2012 00:33
|
|
|
geonetix posted:Let me tell you about offsets that are not whole hours and therefor are not accepted as valid input in so many APIs. The funny thing is that UTC+05:45 is not even the right time in Nepal; it should be UTC+05:41:16 The worst thing is when people take the naive solution of storing the time in UTC, and also storing UTC offsets. This works okay unless you live in any of the many places in the world that cannot figure out what time it should be, and then historical date handling in your app becomes completely and utterly useless.
|
|
#
?
Jan 7, 2012 01:52
|
|
|
There's also the horrible thing about time: it's not a function, continuous or not. There are dates and times that have never happened. There are dates and times that have happened twice or even thrice.
|
|
#
?
Jan 7, 2012 02:08
|
|
|
Couldn't you still map that as a function from {no-nonsense no-readjustment seconds since people agreed that it's 0:00 january 1st 1970 utc; whose local ruleset you are using and which flavor and revision of it} to wallclock time/date? It won't be an nice and pretty function but then what is
|
|
#
?
Jan 7, 2012 03:44
|
|
|
Sure, you can do that. You would need a lot of crazy timezone data like the link ymgve posted. The problem is being able to have a user say "I want an alarm to go off at 1:30 PM on November 4, 2012" and convert that back into a timestamp.
|
|
#
?
Jan 7, 2012 04:49
|
|
|
Yeah I guess we better halt all the trains for an hour so no one runs into any problems there.
|
|
#
?
Jan 7, 2012 05:06
|
|
|
moynar posted:
|
|
#
?
Jan 7, 2012 06:15
|
|
|
Suspicious Dish posted:There's also the horrible thing about time: it's not a function, continuous or not. There are dates and times that have never happened. There are dates and times that have happened twice or even thrice. It gets pretty weird when you get deep into coding time based applications. Makes you kind of philosophical.
|
|
#
?
Jan 7, 2012 07:05
|
|
|
moynar posted:Timezones, weekdays, leap years and clocks are real life horrors. Ugh, corner cases. In a past life I worked for a company that sold time & attendance and payroll systems. Dealing with a particularly prickly DST problem was one of the catalysts for me to quit that job.
|
|
#
?
Jan 7, 2012 09:39
|
|
|
kitten smoothie posted:In a past life I worked for a company that sold time & attendance and payroll systems. Dealing with a particularly prickly DST problem was one of the catalysts for me to quit that job. Maintaining time zone databases was a full-time job for a dude in at least one place I've worked.
|
|
#
?
Jan 7, 2012 11:58
|
|
|
Are none of you aware that there is a single, centrally-maintained time zone database which handles all of those things?
|
|
#
?
Jan 7, 2012 13:09
|
|
|
qntm posted:Are none of you aware that there is a single, centrally-maintained time zone database which handles all of those things?
|
|
#
?
Jan 7, 2012 13:15
|
|
|
The Gripper posted:Wasn't that shutdown pending a lawsuit last year? I don't recall hearing about it reopening (yet), but maybe it wasn't the entire database that was shut down.
|
|
#
?
Jan 7, 2012 13:35
|
|
|
Aleksei Vasiliev posted:IANA immediately started maintaining it and development is still ongoing. Edit; just realized it says it right there in the wiki, immediately below where I skimmed :o
|
|
#
?
Jan 7, 2012 15:14
|
|
|
Hammerite posted:Why would you ever not just use UTC for any and all datetime data? Because users want to get the time they put in back out again. The map from local time -> UTC is not bijective, so you can't always get back to where you started. It's simple really, death to those who supply a time without a timezone attached.
|
|
#
?
Jan 7, 2012 15:18
|
|
|
Zombywuf posted:Because users want to get the time they put in back out again. The map from local time -> UTC is not bijective, so you can't always get back to where you started.
|
|
#
?
Jan 7, 2012 18:08
|
|
|
In my area there is a Sunday each year where 1:30am local time corresponds to two times in UTC. There is another Sunday each year where 2:30am local time has no corresponding time in UTC. Both cases disprove bijection. Colloquially, I live in an area that observes daylight saving time. The point of UTC is, in part, to avoid such silliness where possible (e.g. in a computer program). pokeyman fucked around with this message at 18:36 on Jan 7, 2012 |
|
#
?
Jan 7, 2012 18:34
|
|
|
gently caress time zones and gently caress daylight savings. No reason at all for that hokey poo poo in the modern world. Universal UTC for life.
|
|
#
?
Jan 7, 2012 18:44
|
|
|
qntm posted:Are none of you aware that there is a single, centrally-maintained time zone database which handles all of those things? On one consulting assignment I ended up having to reconcile the following: - a timeclock/payroll system which relies on Java's time calculations, which relies upon these databases (e.g. you punched in at 10p and out at 6a on "spring forward" day, so translating to UTC offsets and subtracting end from start, you worked 7 hours). The system was bult on the fairly reliable assumption that people are to be paid for the time they worked. - A union contract that says people should not be paid based on common sense, and if they work across DST changeovers then they get paid "by the clock." So 10p-6a means they get 8 hours pay, period. So they gain a free hour pay on forward day and get screwed an hour on backward day. - This corner case affected maybe 10 of 10,000 employees, so it could be handled by manual adjustment, and that's how they dealt with it in their previous system. But this client was willing to have us burn tens of thousands of dollars in consulting time to try to automate it. We gave tons of pushback on it because there was no ROI on that spending, and finally they saw it our way after having to have it personally approved by the CFO. I quit that job 3 years ago and went into biotech. Dealing with time is a pain in the rear end. Curing cancer is way easier. kitten smoothie fucked around with this message at 18:51 on Jan 7, 2012 |
|
#
?
Jan 7, 2012 18:48
|
|
|
Jon Skeet has an entertaining section on handling dates and times in software in this talk: http://vimeo.com/7403673 The UTC stuff starts at 16:50 or so. I highly recommend it!
|
|
#
?
Jan 7, 2012 19:31
|
|
|
wwb posted:gently caress time zones and gently caress daylight savings. No reason at all for that hokey poo poo in the modern world. Universal UTC for life. UTC is a good start, but we need to get rid of format issues too. gently caress this month/day/year vs day/month/year vs year/month/day poo poo. Is 3:08 in the middle of the night or the middle of the afternoon? Who knows! I think we should all just use the straight hex representation to keep things simple. If anyone else agrees, meet me at the bar around 0x1CCCD9C11241697 and we'll have a few beers while we plan this thing out.
|
|
#
?
Jan 7, 2012 20:32
|
|
|
wwb posted:gently caress time zones and gently caress daylight savings. No reason at all for that hokey poo poo in the modern world. Universal UTC for life. Daylight savings is dumb, but when you include things outside of software, I think local time solves more problems than it causes.
|
|
#
?
Jan 7, 2012 20:53
|
|
|
First, let's all remember that the concept of time beyond sunrise, noon and sunset is a relatively new concept in human thought. It dates from the 19th century where railroads forced the world to agree on the clock across administrative boundaries. Moreover I think there are a few problems here. The one I'm squarely aimed at is removing the concept of local time and settling on a universal standard. So it is 1700 hours everywhere rather than it being 5:00 somewhere. Obvious side-effect of this is going to a 24 hour clock. But much of the world already is on a 24 hour clock already so I don't think that is that big a challenge. Formats and such typically matter most in electronic data interchange, that is really a moot point for most of the world. We can use the same constructs to express time, except I would be posting this at 2016 rather than 3:16 in the afternoon.
|
|
#
?
Jan 7, 2012 21:17
|
|
|
pokeyman posted:In my area there is a Sunday each year where 1:30am local time corresponds to two times in UTC. There is another Sunday each year where 2:30am local time has no corresponding time in UTC. Both cases disprove bijection. I guess strictly you could say that on the "skip-forward Sunday", 2:30am local time "does not exist", i.e. you view the map from local time to UTC as having a domain that does not include that hour. Your map is then surjective, but not bijective. To make it bijective you need a number line with a "doubled hour", i.e. when times are specified in the local time that lie between 1am and 2am on the "skip-backward Sunday" you need to specify which of the two possible times you mean. This sounds obnoxious but surely you would need that information to do anything useful with the time data (as stated in local time) anyway. If you ask me, say, to give you a phone call at 1:30am on "skip-backward Sunday", I need to know whether you mean 1:30am (before clocks change) or 1:30am (after clocks change) in order to prevent ambiguity.
|
|
#
?
Jan 7, 2012 22:02
|
|
|
Hammerite posted:Why would you ever not just use UTC for any and all datetime data? Suppose a user schedules a your high school bell system to ring at 9:00 AM (EST) on November 2, and that value is stored using UTC. Then Congress decides to extend daylight savings time by a week in the fall. The bell ends up ringing at 9:00 AM (EST) but was really wanted was 9:00 AM (EDT). Another example: You schedule a meeting at 9:00 AM (EST) on November 2, same thing happens. Another example: You schedule an "all-day event" and the software refers to it as an event from 5:00 AM UTC to 5:00 AM UTC the next day. Then daylight savings time get adjusted by Congress and in local time it now appears as 11:00 PM to 11:00 PM the next day in local time. Another example: Somebody's birthday is recorded simply as a date, not as a point in UTC time. (Or if it is you get the birthday wrong because you're in the wrong timezone and it gets converted to the wrong date in your local time.) Another example: Alice is on Venus, Bob is on Mars...
|
|
#
?
Jan 7, 2012 22:46
|
|
|
And this is why all calendaring software is terrible.
|
|
#
?
Jan 7, 2012 22:48
|
|
|
shrughes posted:Another example: You schedule an "all-day event" and the software refers to it as an event from 5:00 AM UTC to 5:00 AM UTC the next day. Then daylight savings time get adjusted by Congress and in local time it now appears as 11:00 PM to 11:00 PM the next day in local time. I don't follow this one at all.
|
|
#
?
Jan 7, 2012 23:20
|
|
|
EST is UTC-5. EDT is UTC-4. Whether a given day is EST or EDT depends whatever Congress feels like doing, and they've changed things in the recent past. There are a bunch of days in the year that used to be EST and are now EDT, and a bunch of days that used to be EDT and are now EST. If you converted midnight to midnight local time on one of those days to UTC based on what the timezone tables were before Congress rejiggered the calendar, you're now off an hour. pseudorandom name fucked around with this message at 00:13 on Jan 8, 2012 |
|
#
?
Jan 8, 2012 00:10
|
|
|
Yeah I see. I misread 5am UTC as being 5am in local time, and couldn't figure out how a change to DST was supposed to translate into a shift of 6 hours in the event's timing. All of shrughes's examples* are just special cases of a general principle which is that if a planned future event is defined in terms of local time, and the local time specified is converted into UTC by software, and then a change to the definition of local time is imposed which is not communicated to the software (or is not adequately dealt with by the software), then the time at which the event is reckoned by the software to take place is incorrect. This suggests that my earlier comments were naive and that in some cases, where events are tied to a particular locality and are defined in terms of local time in that locality, it makes sense to use local time together with information about which locality the event is defined in relation to. (For historical data I still say it makes sense to use UTC exclusively.) *bar the birthday example.
|
|
#
?
Jan 8, 2012 00:52
|
|
|
Now I'm wondering how the US government handles the Martian time zones.
|
|
#
?
Jan 8, 2012 02:47
|
|
|
|
| # ? May 21, 2024 04:20 |
|
|
PDP-1 posted:UTC is a good start, but we need to get rid of format issues too. gently caress this month/day/year vs day/month/year vs year/month/day poo poo. Is 3:08 in the middle of the night or the middle of the afternoon? Who knows! In a way that has happened already.
|
|
#
?
Jan 8, 2012 15:06
|
|
