
If you're using YYYY in your JVM service or %G in anything, fix it now - pinaceae
The single character G instead of Y took down Twitter&#x27;s API today.<p>If you&#x27;re using YYYY in your JVM service or %G in anything, fix it now. You&#x27;re very likely using the wrong year format.<p>date
Mon Dec 29 00:44:45 EST 2014
date -u &quot;+%G&quot;
2015<p>ISO 8601 week numbering has 2015 start this week.
======
claar

      Unix date command: Use +%Y instead of +%G
      Java: Use yyyy instead of YYYY
      Python: Use %Y (ISO-8601 year number is not available)
      PHP: Use Y instead of o
    

Please contribute other languages in replies and I will add them.

(edit: This post had originally suggested the post's title be changed to
mention Java, thus vitno's reply below)

~~~
hobbified
Anything at all with strftime: Use %Y instead of %G. It's a C function, but
many languages (Perl/Python/Ruby/etc.) expose it through their own datetime
libraries.

------
reverend_gonzo
Here's some more information:

The year number of the ISO week very often differs from the Gregorian year
number for dates close to 1 January. For example, 29 December 2014 is ISO
2015-W1-1, i.e., it is in year 2015 instead of 2014.

[http://en.wikipedia.org/wiki/ISO_week_date](http://en.wikipedia.org/wiki/ISO_week_date)

Specifically, you should be using +%Y instead of +%G when passed into date,
and 'yyyy' instead of 'YYYY' when used in Java.

~~~
danielweber
I always wondered "who in the world uses that stuff?" when I read date library
docs. Now I know.

I also remember at one startup when I asked the payroll guy how many pay
periods there were that year, he scoffed "26, it's _always_ 26." Well, not
with years having fractionally more than 26 ^H^H^H 52 weeks there aren't.

~~~
IgorPartola
This is exactly why we should adopt a 13 month calendar, with a Year Day as
the last day of the year. If it's a leap year, there'd be two consecutive Year
Days. These days should be special: they are holidays, so everyone has them
off. This immediately solves the payroll problem for most people: just don't
pay them for this day (obviously adjusting the numbers such that if you make
$60,000/year, you still get that).

For those who work on this day (medical professionals, etc.) the rate is
different (being a holiday and all), so they just get paid by the hour,
regardless of what they do throughout the year.

Your payroll can now be weekly, biweekly, monthly, or whatever you want: you
still get the same amount of money per month. This is nice because you don't
get weirdness with things like rent/mortgage payments which are monthly. For
example, for those who get paid biweekly, you get two months a year where you
get an extra payment. This is silly and leads to more difficult accounting and
budgeting.

Monthly is nice, but lots of your expenses are likely one a week-by-week
basis: groceries, entertainment, etc.

Weekly is AFAIAC the nicest: it is the easiest to budget because it's as close
to the common denominator as possible. However, it is not the LCD, so it still
has the weird problem of getting more money in some months vs others.

~~~
jrochkind1
I like the idea of a day that _everyone_ has off, but I'm not sure you realize
how drastic a change that would be. NO places of business open, no gas
stations, no drug stores, no hospitals, no toll collectors, no trains, plains,
or mass transit -- no police or firemen?

Of course, changing the calendar isn't a realistic plan anyway (Americans
still won't accept the freaking metric system, that's too much change! and of
course there would be costs to having a calendar different than the rest of
the world, unless we get EVERYONE to change). But making _everyone_ have off
is even less realistic. So payroll systems would still probably need to
account for the days.

But I do like the idea of a day or two that literally _everyone_ has off, and
would subscribe to your newsletter.

~~~
tankenmate
Well Arabic countries traditionally use the Islamic calendar (luna based)
rather than the Gregorian calendar (solar based). If memory serves Myanmar
(nee Burma) uses a different calendar as well.

~~~
hrasyid
What's your point? They can afford to switch from Islamic calendar to
Gregorian, because the majority already use Gregorian. It doesn't mean that it
will be easy to make a country switch to a 13-month calendar that nobody else
use

------
ddlatham
Unless you're using Joda Time, where YYYY means "year of era" and will be the
same as yyyy for years since 1 CE.

[http://joda-time.sourceforge.net/apidocs/org/joda/time/forma...](http://joda-
time.sourceforge.net/apidocs/org/joda/time/format/DateTimeFormat.html)

[http://joda-time.sourceforge.net/field.html#yearOfEra](http://joda-
time.sourceforge.net/field.html#yearOfEra)

~~~
skeltoac
Searched my github repo for "YYYY", found two. OH NO! Wait, everything's
working. Huh? Oh, Joda Time. Sweet.

------
protomyth
Unless of course you read the docs and are using YYYY or %G for a proper use.
Gave me a bit of a scare with that headline given one of our scripts uses %G
for reporting purposes. I thought there was an error in %G for this year.

~~~
raverbashing
And what's an example of proper use of this?

(According to man on Mac OSX for G - "This year is the one that contains the
greater part of the week (Monday as the first day of the week)"

~~~
mason55
Say you're doing weekly data processing that always needs to be Sun - Sat.
You'd want yesterday to be the start of week 1 for 2015. Or any sort of data
slicing and dicing that allows viewing by week, you'd want everything from Sun
- Weds of this week to roll up to week 1 of 2015.

~~~
danielweber
> Say you're doing weekly data processing that always needs to be Sun - Sat

Shouldn't that be Mon-Sun? The Sun-Sat week we are currently in is majority
2014, but the Mon-Sun week that started today is majority 2015.

~~~
Sharlin
Yes; ISO weeks are always Mon-Sun.

------
jontas
This also seems to affect PHP when using the formatting character 'o', which
is PHP's version of the ISO-8601 year number. Using 'Y' instead is returning
2014.

    
    
        php > echo date('Y');
        2014
        php > echo date('o');
        2015

~~~
teleclimber
Yup. Got bitten by that last year.

When reading the docs [1] it's pretty obvious which one should be used so I am
left wondering why I ended up with 'o' in my code. I suspect I copy-pasted
something from some random blog post or whatever. Serves me right. :(

[1]
[http://php.net/manual/en/function.date.php](http://php.net/manual/en/function.date.php)

------
K0nserv
This affects Objective-C too as we discovered when a test "randomly" started
failing today. Luckily I procrastinated some on HN and found this post.

[https://gist.github.com/k0nserv/f53084ebb6a753c4905f](https://gist.github.com/k0nserv/f53084ebb6a753c4905f)

------
pyre
From strftime(3):

    
    
           %G is replaced by a year as a decimal number
              with century. This year is the one that
              contains the greater part of the week (
              Monday as the first day of the week).

~~~
s_kilk
I'm puzzled as to why the behaviour of %G would be desirable. Can anyone offer
an example?

~~~
valevk
It is used to get the year, which a week number belongs to. The current week
number (1) belongs to 2015, even though it's 2014. Here, check out this
calendar [0]. We are already in week 1 of year 2015. That's why you get the
year 2015.

Why is it useful you might ask: when you order a time-series by week number,
or if you are grouping by week numbers, you would need the week number of
course. But if the data is spanning over two years, you would need also the
year for grouping, because you would add up weeks from different years. If you
use week number + current year you get errors around the end of some years.

[0]
[http://www.calendar-365.com/2015-calendar.html](http://www.calendar-365.com/2015-calendar.html)

~~~
gpvos
Note that these are international (ISO) week numbers. US-American week numbers
are different, I'm told.

------
NelsonMinar
This same bug is probably what broke iPhones coming out of Do Not Disturb mode
in January 2013. [http://arstechnica.com/apple/2013/01/ask-ars-why-will-
apples...](http://arstechnica.com/apple/2013/01/ask-ars-why-will-apples-do-
not-disturb-bug-fix-itself-next-week/)

------
valevk
So, how do I fix it?

~~~
pkinsky
SimpleDateFormat("YYYY-MM-dd'Z'") -> SimpleDateFormat("yyyy-MM-dd'Z'")

~~~
valevk
Thanks. This seems like a no brainer when you check the Javadoc [0], but I
wouldn't have spent a minute giving it a deeper thought when writing it down.

[0]
[http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDat...](http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html)

------
quicksilver03
Just to reformat your commands:

    
    
        date
        Mon Dec 29 00:44:45 EST 2014
    
        date -u "+%G"
        2015

------
warrenm
source for this statement?

~~~
spatulon
[https://twitter.com/jmhodges/status/549430032616017921](https://twitter.com/jmhodges/status/549430032616017921)

Also
[https://twitter.com/jmhodges/status/549431554879938560](https://twitter.com/jmhodges/status/549431554879938560)
:

 _" (The correct formats are "yyyy" and "%Y". Yes, this matters and is
happening right now. "Week-based years" are a thing.)"_

~~~
mrweasel
Not much of a source really, it's just some random dudes tweet, with no real
explanation. Also it assume (correctly in most case) that %G or YYYY isn't
what you where looking for.

If you're going to throw something like this out on the internet, I would like
it to be more detailed. Just blasting it out on Twitter is pretty useless.

Reproduction: `date -u "+%G"`, sorry but that does EXACTLY what it's suppose
to:
[[http://pubs.opengroup.org/onlinepubs/009695399/functions/str...](http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html)].

Depending on your operating system it's even documented. OpenBSD has a pretty
good documentation for it, while Mac OS X is somewhat lacking, but to the
point where you wouldn't use it without checking what it actually
means.[[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man3/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man3/strftime.3?query=strftime&sec=3)]

Why would you even pick %G if that wasn't what you meant, %Y seems more
obvious. Using YYYY I can understand, it's a bit of gotcha that YYYY is one
thing and yyyy is something less. It even test correctly more often than not.

~~~
dmourati
* Random dude who worked at twitter and cited the people currently working at twitter who found and fixed the problem during the time he tweeted it.

------
fdsfsdaffdsa
yoda time seems not to be affected:

    
    
      * Y       year of era (&gt;=0)            year          1996
      * x       weekyear                     year          1996
      * y       year                         year          1996

~~~
ddlatham
If you mean Joda time, then "xxxx" is also affected (which is correct
behavior):

    
    
      public static void main(String[] args) {
        long now = System.currentTimeMillis();
        System.out.println("YYYY: " + DateTimeFormat.forPattern("YYYY").print(now));
        System.out.println("yyyy: " + DateTimeFormat.forPattern("yyyy").print(now));
        System.out.println("xxxx: " + DateTimeFormat.forPattern("xxxx").print(now));	
      }
    

prints

    
    
      YYYY: 2014
      yyyy: 2014
      xxxx: 2015

~~~
Dylan16807
Nobody will use xxxx by accident, so it's not 'affected' by any
problem/confusion, it's just there doing what the developer intended.

------
gred
We ran into this bug in production today (I don't work at Twitter).

------
artenix
Any confirmation if that was the error which took Twitter down yesterday?

------
Tharkun
Thank you, kind stranger, you just saved my job.

------
fredgrott
interesting little bug...data formats are always fun for interesting bugs like
this

------
sirwolfgang
Relevent: [http://xkcd.com/1179/](http://xkcd.com/1179/)

